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APFUCATION PROGRAMS USING AN 

ATTRIBUTIVE DATA MODEL DATABASE The use of these conversion programs and the rede- 

5 sign of the application programs to achieve integration 

RELATED APPLICATION require considerable time, effort, and expense. This 

This application is related to U.S. Ser. Na 181,105, time, effort and expense GJ^tically mcreases with the 

entitled "Data Processing System Having a Data Struc- number of programs to be integrated, 

hire With a Single, Simple Primitive" by Edward S. To obviate the need for additional conversion pro 

Lowry, filed Apr. 13, 1988. 10 grams, common databases have been adopted to store 

data in memory in an area which is accessible by the 
BACKGROUND OF THE INVENTION different programs. Systems using a common database 
This invention relates generally to the field of data- only require each applicaation program to have an in- 
bases, and more specifically to the uses of common terface with the common da t a b ase. Such interfaces 
dtttatem by several application programs. 19 convert data output by an application program into a 
Often many different application programs must be common format for storage at the common database, 
adapted to share or exchange information with other and convert the data from its common format into a 
programs in a computer system. One notable example is format in the common database acceptable for the appli- 
a set of interactive computer programs which provide cation programs. Common database systems which are 
ft syVyirr* m the design and manufacture of products. 20 known or used to store data include, for example, the 
Such interactive programs typically include computer- "relational," "functional," and "Codasyr data models, 
aided design (CAD) programs and computer-aided Although common database systems using conven- 
manufacruring (CAM) programs that are used in the tional data models overcome the threshhold problem of 
development of products. Other examples of applica- program integration described above, the use of con- 
tion programs often requiring information exchange are 25 veronal ^ta models presents distinct programming 
document retrieval programs and project mana ge me nt ^ performance problems for the integrated programs, 
programs. For one discussion of the programming and perfor- 
in such systems, output data from one application mance problems presented by conventional data models 
program is often input data for one or more other appli- ^ u s No 4^3 1,664 issued to Charles W. Bach- 
cation programs. For example, the output data of a 30 m3JL 

CAD program used to develop the design of a circuit Accordingly, ft b an object of the present invention 

board may be used as mput data for a CAM program provide a nethod for integrating several application 

wmch facilitates niaimfacture of the designed circuit ^ a oommo|l structure in a manner 

bo f rd l_ J r , . . r „ 1;^*;^ i< which reduces the need and complexity of additional 

g£S^°T^^ 35 -version programs or redesign of application pro- 

mu^S^ ^also an object of the P-nt mvention to provide 

u^p^^uSr^^t be prepared and preZ * program integration method which overcomes the 
n^form wn*h is acceptable for^by the Jpp£ 40 Poetical ^ocmance problems «cooM by com- 
cation program which 0,^00 thedata. ^^iclnon "™ database conventional data mod- 

teE^^^^^^ 1 ^^ 8 ^ 40 » is another object of this invention to provide a 
Sv^integration between pairs of software ap- means for maiiaging the access to such a common data 
plication programs is a relatively simple task. Such 45 structure by application programs, 
motion merely requires inodification to one or both Yet another object of the present invention is to pro- 
of the two application programs sought to be inte- vide a common data structure which can be easily 
gnlal adapted to a data processing system with auxiliary 

Achieving integration among several other applica- memory, 
tion programs, on the other hand, becomes increasingly 50 It a a further object of the present invention to ex- 
complex as the number of programs increases. Integral- press information in application programs using only a 
ing several programs is not urx»mmoii, however. For single primitive element which can represent the corn- 
example, one CAD program for designing integrated pl«* mterrelationships of application program lnfonna- 
drcuits may need to be integrated with another CAD don. . 
program for designing circuit boards as well as with a 55 Additional objects and advantages of the invention 
CAM program to manufacture the boards. will be set forth in the description which follows or may 

Typically, the integration of one application program be learned by practice of the invention, 
with several other application programs is achieved by SUMMARY OF THE INVENTION 

designing the first program to be integrable with each of 

the other programs. This design strategy, however, 60 To achieve the foregoing objects, and in accordance 
requires detailed knowledge about the input require- with the purpose of the invention as embodied and 
ments of each program and may require redesign of the broadly described herein, a data structure for access by 
first application program each time a new application a plurality of application programs is created from sin- 
program is added. If the other application programs are gle primitive data elements or attribute data objects, 
instead redesigned for integration with the first applica- 65 According to the present invention, a the data structure 
tion program, similar problems arise. in a memory coupled to the data processor. The data 

Alternatively, a conversion program may be used to structure is crea ted using data originating in the applica- 
integrate the first application program with the other tion programs and including node data and node data 
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descriptors. Specifically, the method of creating the FIG. 9 shows a block diagram of an element header, 
data structure comprises the steps, executed by said data block shown in FIG. 8; 

processor, of creating a different one of the attribute FIGS. 10A and 10B show block diagrams of the 
data objects for each of the node data and organizing preferred embodiment of a relation sub-block shown in 
the attribute data objects hierarchically according to a 3 FIG. 8; 

being-held relationship by choosing from the attribute FIG. 11 shows a block diagram of the preferred em- 
dato objects for each of the attribute data objects, a bailment of a "held" object sub-block shown m FIG. 8; 
holder £to object such that a hierarchical being-held FIG. 12 shows a block diagram for a plural relation 
relationship exists between each attribute data object header block shown in FIG. 8; : 
and a single holder data object 10 FIGS. 13A and 13B shows block diagrams of the 

The method further comprises the step of establishing preferred ernbodiments of two kinds of plural relation „ 
non-hierarchical relationships for selected ones of the sub-blocks shown in FIG. 8; 

attribute data objects created from node data associated FIG. 14 shows a block diagram of the preferred em- : 
with at least one of said node data descriptors by choos- bodiment of an instance root block shown in FIG. 8; 
ing, from the attribute data objects, referent data objects 15 FIG. 15 shows a block diagram of a preferred cm- . 
for the selected attribute data objects. Each chosen bodiment of a dictionary tile shown in FIG. 6; 
referent data object reflects a node data descriptor of FIG. 16 shows a block diagram for the basic structure , 
the node data for which a corresponding selected attri- and contents of the preferred embc<iiment of either an 
bute data object was cheated. The sdected attribute „ apex block or a context block shown in FIG. 15; 
objects are called relation data objects and the attribute 20 FIG. 17 shows a block diagram of a preferred em- 
data objects without referent data objects are called bodiment of an element type block shown in FIG. 15; 
element data objects. FIG. 18 shows a block diagram for an attribute type 

The method further includes the steps of creating an block shown in FIG. 15; - > 

apex data object with which at least one of the attribute FIG. 19 shows a preferred embodiment of a block 
data objects has a beiiig-beld relationship, the apex data ^ diagram of an index branch block in accordance with 
object having no being-held relationship with any of the the present invention; 

attribute data objects, creating an attribute file for the FIG. 20 shows a block diagram of a preferred em- 
attribute data objects, and entering each of the attribute bodiment of an index branch header block shown in 
data objects into the attribute file. 30 FIG. 19; 

Also according to the present invention, the method FIG. 21 shows a block diagram of an index branch 
comprises the steps of entering holding pointers for sub-blocks shown in FIG. 19; 

each of the attribute data objects into said attribute file, FUG, 22 shows a block diagram of a preferred em- 
the holding pointer of each attribute data object indicat- bodiment of an index directory block shown in FIG. 8; 
ing the one of the attribute data objects having a being- 35 FIGS. 23A and 23B show a flow diagram depicting 
held relationship with that attrfrute data object, and the steps involved in a preferred method of creating an 
entering referent pointers into the attribute file, the elemen t data object according to the present invention; 
referent pointers reflecting the non-hierarchical rela- FIGS. 24A and 24B show a flow chart depicting the 
tionships between the attribute data objects. steps involved in a preferred method of creating a rela- 

The accompanying drawings, which are incorpo- 40 tion in accordance with the present invention; 
rated in and which constitute a part of this specification, FIG. 25 shows a flow chart depicting the steps in- 
illustrate an embodiment of the invention and, together volved in the preferred method of erasing a relation in 
with the description, explain the principles of the inven- accordance with the present invention; 
t ^ Qn FIG. 26 shows a flow chart describing the steps in- 

4< volved in erasing an element data object in accordance 

BRIEF DESCRIPTION OF THE DRAWINGS with the present invention; 

FIG. 1 shows an example of a data processing system FIGS. 27A and 27B show a flow chart describing the 
in accordance with the present invention; steps involved in the preferred method of accessing the 

FIG. 2 shows an example of an attribute data object common data structure in accordance with the present 
as taught by the present invention; 50 invention; 4 

FIG. 3 is stjows a circuit for use in fflustrating the use FIG. 28 shows a flow chart describing the steps m- 
of Attributive data model of the present invention; volved in an alternative preferred method of accessing 

FIG. 4 is shows a data structure for representing the the common data structure using key values in accor- 
circuit of FIG. 3 according to the Attributive data dance with the present invention; 
mode. 35 FIG. 28A shows an index result block; 

FIG. 5A shows a block diagram of certain compo- FIG. 29 shows a detailed block diagram of a pre- 
nents of a software system in accordance with the pre- ferred embodiment of common data structure 14C in 
ferred embodiment of the present invention; accordance with the present invention; 

FIG. 5B shows a block diagram of certain compo- FIG. 30 shows a block diagram of a preferred em- 
nents of a software system in accordance with an alter- 60 bodiment of the rx»nter/counter section of a controller 
nate embodiment of the present invention. shown in FIG. 29; 

FIG. 6 shows a portion of the contents of a memory FIG. 31 shows a block diagram of version blocks, 
system containing a data structure including a plurality shown in FIG. 29; 

of files in accordance with the present invention; FIG. 32 shows a block diagram of switch blocks 

FIG. 7 shows a 32-bit longword used as a pointer in 63 shown in FIG. 29; 
the preferred embodiment of this invention; FIG. 33 shows a flow chart describing the steps m- 

FIG. 8 shows a more detailed block diagram of the volved in updating data structure 14C in accordance 
constituent portion of the attribute file shown in FIG. 6; with the present invention; 
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FIG. 34 shows a flow diagram for a preferred COM- Each attribute data object 200 b related hierarchi- 

MTT routine indicated in FIG. 33; cally to a holder attribute data object 210. Holder attri- 

FIG. 35A, 35B and 35C show flow diagrams of the bute data object 210 is the attribute data object which 

procedures followed in the initial, intermediate and final has a holding rela t ionshi p with attribute data object 200. 

housekeeping steps, respectively, of the COMMIT rou- 3 Conversely, attribute data object A 200 has a being-held 

tine shown in FIG. 34; and relationship with attribute data object 210. 

FIG. 36 shows a preferred embodiment of a flow The non-hierarchical or pointing relationship de- 
chart for accessing the desired version of common data scribes the relationships between the information repre- 
structure 140* in accordance with the present invention. «nted by attribute data objects. Certain attribute data 

_ io objects may also be related to a single referent attribute 

DESCRIPTION OF THE PREFERRED data object to reflect the pointing relationship. A refer- 

EMBODIMENTS ent attribute data object 220 represents the information 

Reference will now be made in detail to presently which has a noz^erarchal ij^^^.]^^ ^ 

preferred mbodiments of this invention, examples of "nation represented by attributedata object 200. 
which are illustrated in the accompanying drawmgs. «" Each attribute data object 2Wmay aho be related to 

wDoareiuu»iwwiauic«u« type data which describes the relationship between the 

A. Common Database Structure attribute data object 200 and those attribute data objects 

100 includmg teMpoc*** (O^ HO and a ^ objcct to ." 

rnemory 120. CPU 110 can be any standard and com- 20 There are only a few rules which the attribute data 
rnon* kr*wn cenmil pnxessmg umt^ and memory 120 ^ m accordance with this invention, 

can include magnetic core, tcnncomiKctorl^^- Although eacHttribute data object may hold several 
net»c disks and mam^c tapes, or any other known ^Xbute data objects, each attribute data object 
memory device. CPU 110 can also represent several ^ ^ ^ a htka g^ A rdrfonsfcp with a single 
independently running central processing units which ^ ^ Thus, each attribute data 

may be "tcuj^g apphcatKm programs simultaneously ^onlyant attribute data object. 

As shown m FIG. 1. application programs 130, 132, and One kind of attribute data object, the dement data 
134 are alternately executed by CPU 110. FIG. 1 shows OT elemeQt> docs not have a separate referent 

CPU 110 executing application program 130 while ap- M attri bnte data object because dements are considered to 
plication programs 132 and 134 are stored in memory "point to 1 * themselves, Lcl, each dement is its own refer- 
120- ent Another kind of attribute data object, the relation 

In accordance with the present invention, application ^ a related to a single separate referent attri- 

programs 130, 132, and 134 share a common data struc- fa U object Each attribute data object may be a 

ture 140 which is based upon an Attrftrative data model 35 referent attribute data object for a plurality of attribute 
The Attributive data modd represents all of the infor- data oojects. 

iiiation accessed by application programs 130, 132 and Basic to the Attributive data modd is the concept 
134 as various combinations of a single primitive. In that the single primitive element the attribute, can rep- 
general, application programs 130, 132, and 134 have resent complex information in other databases. An attri- 
their own databases which contain data either in the expresses the idea that one thing is attributed to 

Attributive data modd's format or in some other for* another thing. For example, things normally attributed 
mat If the application program information is not in the to ^ automobile include its color, its engine, and its 
Attributive data modd format it is converted into that owner. To organize complex H n tni»^ around the attri- 
fbrmat by means described below* In this manner, data bute as a primitive represents the view that a database is 
structure 140 can be accesse d by each of the application 43 basically a collection of attributions. Common data 
programs 130, 132, and 134. structure 140 is a concrete representation of that view. 

The common data structure 140 is different from As ir vl"^* 1 **, elements or element data objects are 
more conventional database systems by the unique data attribute data objects which refer to themsdves, or in 
structures which are created and accessed by the apph- other words have only a holder attribute data object 
cation programs. The Attributive data modd uses, as its 50 and no separate referent attribute data objects. An ele- 
single primitive, an attribute or attribute data object ment can r ep r esent a thing, such as an automobile, an 
which contains certain hierarchical information about engine, a version of a multiplier circuit or a signal, 
its relationship with other attributes, and which can Elements which have a being-held relationship with an 
"point to" attributes to reflect a non-merarchical rda- element can, for example, represent the internal struc- 
tionship. The use of toe attributes in accordance with 33 ture of the thing represented by that element For exam- 
the present invention is limited by the use of certain pie, if an dement represents an engine, other dements 
simple rules. These limited number of rules allow the having a being-held relationship with the dement repre- 
attributes the flexibility to accurately represent complex senting the engine can include the pistons, the cylinders, 
objects and relationships. and the rings. 

FIG. 2 shows an example of an attribute data object 60 Each embodiment of data structure 140 has one attri- 
200. Attribute data object 200*5 hierarchical relationship bute data object which does not have a being-held rela- 
with other attribute data objects is denoted as a holding bonship with another attribute data object. That ami- 
or being-held relationship. In general, each attribute bute data object is called the apex or apex attribute data 
data object can have a being-held relationship with (Le., object and holds at least one other attribute data object, 
can be held by) only one other attribute data object but 63 In addition to the requirement of a single apex attribute 
each attribute data object can have a holding relation- data object and the single holder for each attribute data 
ship with (Le., can hold) several other attribute data object each embodiment of data structure 140 has the 
objects. configuration of attribute data objects in accordance 
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with the invention such that it is possible, but not neces- labels for other elements, and attribute data object 420 

sary, to create the configuration by starting with the (CPU element) holds elements 470, 472, 474, and 476 

apex and by adding the other attributes, one at a time, in which represent signal elements, 

a holding relationship. This restriction creates a hierar- The hierarchical arrangement of attribute data ob- 

chy and prevents certain circular or loop configura- 5 jects gives rise to a "containment tree," which is used to 

toons, such as when a first attribute data object has a contain the attribute data objects that collectively rep* 

holding relationship with a second attribute data object, resent conceptual objects. A containment tree of an 

which in turn has a holding relationship with a third attribute data object, called the root attribute data ob- 

attribute data object, which then has a holding relation- ject or root of the containment tree, includes all attri- 

ship back with the first attribute data object Such a 10 bute data object, held by the root (i.e., directly held), as 

configuration would not be hierarchical according to well as all attribute data objects held by any other attri- 

this invention. bute data objects in the containment tree (le., indirectly 

The relation or relation data object, as explained held). An attribute data object hdd directly or indi- 
above, is an attribute data object which is related to a reedy by another attribute data object is said to be "con- 
referent attribute data object different from the attrib ute 15 tained" by that other attribute data object or in that 
d fltt object itself. Relations can have a being-held rela- other attribute data object's containment tree. In a con- 
tionship with elements, for example, if an element repre- tainment tree, the conceptual object represented by that 
scats a multiplier circuit, one relation can attribute to tree corresponds to the root All other attribute data 
that element a previous version of the multiplier. In objects in the containment tree represent conceptual 
addition, relations can have holding and being-held 20 sub-objects, such as components, listed items, or rela- 
relationships with other relations. For example, if a first tionships within the conceptual object represented by 
relation attribute data object attributes a part number to the tree. The attribute data objects in a containment tree 
a multiplier, that first relation attribute data object may may also represent rela t ionships with attribute data 
hold a second relation attribute data object which attri- objects outside the containment tree, 
butes to the first relation attribute data object die date 25 In FIG. 4, the containment tree for circuit element 
on which the part number was assigned to the multi- 430 would include gate elements 450 and 460, and the 
plier. relation data objects held by gate elements 430, and 450 

The Attributive data model can be better understood (Le., the relation data objects pointing to elements 440 

by an example. FIG. 3 shows a circuit including two and 468 and the relation data object pointing to element 

AND gates, 320 and 330, having three inputs and two 30 462), the elements held by element 450 (Le., pin ele- 

inputs, respectively. The inputs of AND gate 320 are ments 480, 4*2, 486, and 488), and the relation data 

322, 324, and 326, and the inputs of AND gate 330 are objects held by pin elements 480 and 488 (Le., relation 

332 and 334. Input 322 of AND gate 320 is driven by data objects pointing to elements 464> 470, 472 and 466). 

output 336 of AND gate 330, and input 334 of AND The use of a containment tree, as explained in detail 

gate 330 is driven by output 328 of AND gate 320. 35 below, simplifies operations such as erasing complex 

The circuit in FIG. 3 can be represented according to objects. As an example, erasure of an object involves 

many different data models. For example, if it were the removal from the common data structure of the 

represented by a relational data model, there would be corresponding containment tree. This invention allows 

separate tables for gates, inputs, and loads of the gates. all attribute data objects in that tree to be identified 

Those tables would then contain identifiers of entries in 40 quickly, making feasible the elimination of random 

the other tables. pauses caused by automatic garbage collection com- 

FIG. 4 shows a data structure 400 representing the manly used in prior art databases, 

information in FIG. 3 in accordance with the Attribu- FIG. 4 also contains several other attribute data ob- 

tive data model of this invention. Data structure 400 can jects, which are representative of information describ- 

be stored in the common data structure 140 in FIG. 1. 45 ing each of the things in FIG. 3 represented in FIG. 4 by 

Data structure 400 includes an apex 410 which, as attribute data objects. For example, attribute data ob- 

described above, does not have a being-held relation- ject 430 holds a relation data object pointing to the 

ship with any other object In addition, apex 410 holds name "xyz." This relation data object has M xyz" as a 

(Le., has a holding relationship with) CPU attribute data referent attribute data object The name "xyz" is ele- 

object 420, which can also be a context The context is 50 ment 468. In a similar matter, element 450 has a relation 

a construct to facilitate naming of attribute data objects, data object pointing to element 462, which is the num- 

because those names have meaning only in the context ber (320) of the AND gate in FIG. 3 represented by 

holding the named objects, and to establish holding element 450. 

relationships for attribute data objects that are associ- FIG. 4 shows other relations as well. For example, 

ated with the context, like the circuits and signals in 55 elements 470, 472, 474, and 476, representing signals 

FIO. 3. such as SI and S2, are organized into a linked list which 

CPU attribute data object 420 holds attribute data is represented by a series of relations. Furthermore, 

objects 430 and 440 which are circuit elements. Attri- attribute data object 480 also holds a relation pointing to 

bute data object 430 re pr e sen t s the circuit in FIG. 3. attribute data object 470 showing that the signal repre- 

Attribute data object 430 in turn holds two attribute 60 sented by that object is an input to the gate represented 

data objects 450 and 460 which are gate elements. Gate by object 450. The converse relationship is also repre- 

element 450 in turn holds four attribute data objects 480, sented by a relation held by element 470 pointing to 
482, 486 and 488 which are pin elements. In this way, a element 480. The name of the signal represented by 

hierarchical holding relationship is imposed upon the attribute data object 470 is reflected by the relation held 

information in FIG. 3. 65 by attribute data object 470 and pointing the attri- 

As FIG. 4 shows, the other information from FIG. 3 bute data object 90, which represents the label "SI." 

is also hierarchically organized. Apex 410 also holds Preferably, a simple constant such as the integer 35 

elements 462, 464, 466, 468, 490, and 492 representing or the character "K," is an element and is represented 
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by a single attribute data object held by the apex. A gram 580 then converts those held attribute data objects 
character string is also preferably an clement held by into the format applicable for application program 530 
the apex. The character string element, however, holds and transmits those converted attribute data objects to , 
a list of relations to its constituent character objects. application program 530. , 
Thus, for example, the string "CAT* could be repre- 5 In accordance with the present invention, the data 
seated by an element data object which held first rela- processing system also includes means for retrieving 
dons to three other element data objects or elements: from the common data structure information from all 
the letters **C" **A M and "T." The ordering of those attribute data objects of a specified type. Retrieval pro- 
letter elements to form the character string "CAT' gram 580, in response to such a request from application 
could be represented by second relations that organize 10 program 530, searches the common data structure 140 
the first relations into a list For example, the relation in slave database 530 for all attribute data objects of the 
from -CAT* to "C* would hold a relation whose refer- specified type. When those specified attribute data ob- 
ent data object is the relation from "CAT* to "A." jects are found, the attribute data objects are extracted, 

converted into the appropriate format, and sent to re- 

a Software Utility Organization iS trieval program 580* 

FIG. 5A shows a block diagram of certain compo- Preferably, retrieval program 590 performs the same 

nents of a software system in accordance with the pre- functions as retrieval program 500. The only functional 

ferred embodiment of the present invention. The opera- difference between retrieval programs 580 and 590 

don of certain of these components is presented in a would reflect the manner in which information is trans- . 

later section. AH that will be described with regard to 20 mitted to application programs 530 and 560. For exam- 

FiQ. 5 A is the major functions of each one of the com- pie, retrieval program 590 could perform a series of 

ponents and their relationship to other components. retrievals as described above, converting the data so 

Preferably, the common data structure 140 shown in obtained into appropriate format for application pro- 

FIG. 1 includes a master database 510 and a slave data* gram 560, and write this data into a file 595. Application 

base 520. Any updates to the common data structure 23 program 560 would then read the retrieved data from 

140 are made to master database 510, and a copy of it is file 595. 

later made to form the next version of slave database Further in accordance with the present invention, the 

5^0. data processing system includes means for creating a 

In FIG. 5 A, 530 and 560 represent two application new attribute data object in the common data structure 

programs, such as the application programs 130, 132 30 from an identification of the attribute data object de- 

and 134 in FIG. L In with the present in- sired to be the holding attribute data object for the 

vention, the data processing system includes means for created attribute data object. That creating means could 

retrieving from the common data structure the referent also include means for creating the new attribute data 

attribute data object for a specified relation data object object from an i denti fic ation of a referent data object as 

For application program 530 shown in FIG. 5A, re- 33 well to form the created relation data object 

trieval program 5S0 performs such retreival function. FIG. 5A shows different ways for creating new attri- 

The slave database 520 provides the actual data to the bute data objects in the common data structure 140 

application programs 530 and 56a according to the preferred embodiment of the inven- 

The details of an exemplary embodiment of portions don. For example, application program 530 uses con- 
of a retrieval program 580 are discussed in a later sec- 40 verter program 540 which receives the necessary infor- 
tion. In general, however, application program 530 mation from a da t a b as e in application program 530, 
specifies a relation data object to retrieval piogiam 580 extracts the needed information for forming common 
and asks for the referent data objects) for that specified data structure 140 in master database 510, and then 
relation data object Retrieval program 580 then constructs attribute data objects by determining the. 
searches the slave database 520 for the specified relation 45 bolder attribute data objects and the referent data ob- 
data object When that specified relation data object is jects. Converter program 540 then sends these attribute 
obtained, retrieval program 580 copies the desired ref- data objects to master database 510 for storage, 
erent attribute data objects), performs any conversion As another example, information created in applica- , 
necessary to place the referent data object into the for- don program 530*8 database can be sent to master data- 
mat applicable for application program 530, and returns 30 base 510 as follows. First, application program 530 
the formatted referent data object to application pro- sends a request to update synchronizer 550. This request 
gram 530. include* information charactrriring the desired update. 

The data structure of the present invention also in- Update synchronizer 550 then modifies master database 
eludes means for retrieving from the common data 510 by signaling converter program 540 to modify mas- 
structure all of those attribute data objects which have 55 ter database 510 by creating attribute data objects in 
a being-held relationship with a specified attribute data common data structure 140 using information from 
object Again, retrieval program 580 in the pre f erred application program 530. Update synchronizer may also 
embodiment shown in FIG. 5A performs this type of be used to create attribute data objects in master data- 
retrieval also. In operation, application program 530 base 510 in accordance with the characterization infor- 
specifies an attribute data object and asks for all those 60 mation in the update request 

other attribute data objects which are held by the spec*- Preferably, converter program 570 performs the 

fied attribute data object Retrieval pr ogr am 580 then same functions as converter program 540. The only 

translates request into an appropriate format, and difference between converter programs 540 and 570 

searches through the slave database 520 until the speci- shown in FIG. 5A is the manner in which information is 

fied attrmute data object is located. Once the specified 63 transmitted from application program 560. Application 

attribute data object b located, retrieval program 580 program 560 first writes data into a file 565. Converter 

obtains copies of all of the attribute data objects which program 570, after receiving a signal from update syn- 

are held by that specified data object Retrieval pro- chronizer 550, reads file 565 and creates attribute data 
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objects in common data structure 140 of master data- portions of storage management software 566 will be 

base 510 m accordance with data m file 565. explained in greater detail below. 

Modifications of master database 510 and signals to C Data Structure Representation of the Common 

converter programs 540 and 560 are performed by up- Database 

date synchronizer 550 to ensure that master database 5 In a preferred embodiment of the invention, common 

510 is updated ma regular and nomnterrupdv^ data structures 140 or 140* are stored in memory 120 

while the common data structure 140 in master database along with application programs such as programs 132 

510 and slave database 520 are used by application pro- and 134. This arrangement is shown schematically in 

gramTupon completion of mentions to master FIG. 6 as is the preferred organizatwnal structure of 

database 510 byconverter program 540 or converter 10 common da* structure 140 into a plurality of files. 

pr^S70,ac^ As FIG. 6 showj the (gnomon data structure 140 

of master daibaW 510 is then made available as a new portion of memory 120 preferably mcludes an attribute 

!!l^!^f^rXtoKaJ «f w it mflv he accessed ^ 600 f a dictionary file 700, and an index file 800. Prior 

IV^^Z^t^^ to a detailed explanation of these files, a general descrip- 

by Cfflc^^ * *>° 2252; f TS^J TJT™ to facUitatc 

***^^^J^^*<™ ^^^S^p^y^ all of the attri. 
data structure. This u sometnn« kno wn as an erase Q r, more precisely, a memory area or 
operation and is easily performed due to the haerarch.- ^ • da* objcc £, m the 
cal oata arrangement ofthe common ^ f ^ mbottocnt of attribute file 600, the attribute 
In the preferred embodiment^ a database moAfying ^ata objects, including both as element data objects and 
program such as converter 540 first locates a specified ^ objects, are organized in a nianner which is 
attribute data object in response to a request received ccmsiste|U McmnaticTin the databases of pro- 
from application program 530. Then converter 540 430, 132 and 134. For example, in a manner de- 
removes the attribute data object from the common ^ ^-^4 m greater detail below, node data and node data 
data structure 140. descriptors of the databases are corresponded to ele- 
In addition, application program 530 can request not ment ^ Tt i il ^ Dn data objects, and the hierarchical 
only that the specified attribute data object be removed, holding relationship is imposed on the attribute data 
but also that the entire containment tree for that attri- Ejects in a logical manner designed to facilitate the 
bate data object be removed. In response to such re- ^ access to ^ identification of desired attribute data 
quests from application program 530, converter 540 objects. 

locates the specified attribute data object Converter Dictionary file 700 preferably includes data entries 

540 also locates all attribute data objects which are held f or the apex and other contexts, as weD as information 

by die specified attribute data object Converter 540 descriptive ofthe type of attribute data objects in attri- 

traverses through the containment tree by examining 35 hate file 600. The data entries for the apex and contexts 

holding relationships and locating all of the attribute could instead be stored in the attribute file, but those 

data objects which are held directly or indirectly by the entries have been stored in dictionary file 700 in the 

originally specified attribute data object Converter 540 preferred embodiment of the invention because that file 

removes all located attribute data objects from common ^ treated primarily as a read only file, and the apex and 

data structure 140. 40 context data generally do not change. 

FIG. 5B shows a block diagram of an alternate em- Index file 800 preferably includes information used by 

bodiment of the components of the software system in CPU 110 to obtain quick access to attribute data objects 

common data structure 140*. The items surrounded by m the attribute file. Index file 600 is designed to take 

the dotted line, application program 530, converter advantage of certain features of many practical tmple- 

program 540 and retrieval program 58% are essentially 45 mrfl tftti<w»« of data structure 140 to increase the effi- 

identical to the corresponding elements in FIG. 5 A. ciency with which data structure 140 may be used. 

Common data structure 140" in FIG. 5B contains a In the preferred embodiment ofthe present invention, 
master data file 515 and a snapshot data file 525. Like attribute file 600, dictionary file 700, and index file 800 
slave database 520 of common data structure 140, snap- in g a m m o n data structure 140 are maintained in a **per- 
shot file 525 of common data structure 140* contains at 50 manent" memory section of memory 120, such as a disk- 
least one complete copy of a version of master data file When CPU 110 needs to access certain portions of files 
515. However, unlike slave database 520, snapshot file 600, 700, and 800, CPU 110 transfers those portions to a 
525 is dfffjgnfd to represent a plurality of versions of primary memory, such as semiconductor RAM mem- 
master data file 515 by storing portions of master data cry. The permanent memory is relatively large in corn- 
file 515 which have been updated. In con tr ast, slave 55 parison with the primary memory and CPU 110 pref era- 
database 520 is designed to represent complete copies of bly manages the flow of data between the permanent 
the current version of master database 510. Common memory and the primary memory in using known vitual 
data structure 140' also includes a control file 555 which memory techniques and in a pref erred manner set forth 
includes data necessary for the control of the common below. 

data structure 140' as well as certain locks to prevent 60 Preferably* data in each of the files in common data 

simultaneous access of structure 14ff by several appbea- structure 140 are grouped in macropages. Each macrop- 

tion programs. Two of the locks which are shown are age is a contiguous 64K byte portion of a file which 

ALTER lock 568 and DBC lock 569. These are ex- consists of 128 512-byte pages. In known embodiments 

plained in greater detail below. of the invention, attribute file 600, dictionary file 700, 

In addition, storage management software 566 is 63 and index file 800 have permitted up to 16K macropages 

shown as providing an interface between common data of storage. 

structure 140' and the software encompassed by the In the preferred embodiment of this invention, the 

dotted lines in FIG. 5B. A preferred embodiment of standard unit of data in attribute file 600, dictionary file 
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700, and index file 800 is a loogword composed of four Finally, attribute file 600 includes instance root 
bytes or 32 bits. The pages or macropages of the files blocks 625 and index dictionary blocks 630, only one of 
typically include several blocks each of which consists each of which is shown for simplicity. These two blocks 
of a group of several longwords. Often the longword is are described in detail below. 

used as a pointer. 3 FIG. 9 shows a block diagram of element header 

FIG. 7 shows a 32-bit longword 615 used as a pointer. block 604 in the preferred embodiment of the invention. 
In the preferred embodiment, CPU 110 derives long- In this embodiment, each attribute data object in data 
word pointers for each of the data Mocks in the files of structure 140 would be represented by an element 
common data structure 140. header block, such as element header block 604. As 

According to the preferred embodiment, Longword 10 shown, element header block 604 includes six long- 
pointer 615 includes a leftmost bit, or TEMP field 616, words 900, 920, 925, 930, 933, and 940. 
which indicates whether the block of memory to which Longword 900 preferably includes a blank field 905, 
this pointer -points" is not part of the permanent data a SIZE field 910, and a CLASS field 915. SIZE field 
structure, in which case the rest of the pointer is the 910 indicates the number of longwords in element 
virtual address of the block in primary memory. The 15 header block 604. CLASS 915 indicates that block 604 
other fields shown in FIG. 7 apply only when the is an element header block. 

block is part of the data structure located in perma- Longword or TYPE DEFINITION pointer 920 
nent memory and transferred primary memory as specifies a location in dictionary file ,700 containing 
oeeded. element type information for .the represented element 

KIND field 618 is two bits long and designates the 20 Type information could also have been made available 
kind of block to which loogword pointer 615 points. to common data structure 140 by some other means, for 
For example, in the preferred embodiment, this field example, through the use of a special compiler which 
indicates where the block pointed to is in attribute file also could establish the apex, other contexts, and identi- 
600, dictionary file 700, or index file 800. fiers for contexts. 

The next field, R field 620, is one bit wide. R field 620 25 NEXT and PREVIOUS pointers 925 and 940, re- 
is presently reserved to allow an additional land of spectively, designate the locations of element blocks for 
pointer to be defined for use with the present invention. attribute data objects having the same holder attribute 

The final field of longword pointer 615 is OFFSET data object as the represented element. In the preferred 
field 622 which comprises the twenty-eight rightmost embodiment of the present invention, attribute data 
bits of longword pointer 615. OFFSET field 622 identi- 30 objects of a common type having the same holder attri- 
fies the referenced information by specifying the loca- bnte data objects are linked by use of these longword 
tion of that information as a longword offset from the pointers. The NEXT and PREVIOUS pointers 925 and 
beginning of a file containing the referenced Mock. 940, respectively, effect such linking. 

The pointers used in the preferred embodiment are HOLDER and REFERENCES pointers 930 and 935 
not the only ones necessary to effect the present inven- 35 of element header block 604 respectively indicate the 
tion. For example, the pointers can directly indicate the hierarchical being-held relationships and non-hierarch- 
locatkmof the corresponding items or can indicate that ical relations between the represented element and 
location indirectly through procedures such as indirect other attribute data objects represented in attribute file 
or indexed addrrflstng 600. HOLDER pointer 630 points to the element block 

40 for an attribute data object, Le., the "holder object" 
1. Attribute Rle with which the represented attribute data object has a 

FIG. 8 shows a more detailed block diagram of the being-held relationship. Thus, HOLDER pointer 630 
constituent portions of attribute file 600. Attribute file points to die element block of the attribute data object 
600 includes several element blocks. Only one element which holds the attribute data object represented by 
block is shown, however, for simplicity, and for de- 45 element block 602. 

scription purposes in this section, the attribute data The REFERENCES pointer 935 points to a first of a 
object represented by element block 602 will be called sequence of plural relation blocks (eg., block 610 in 
the "represented element'* The element block is the FIG. 8) in attribute file 600. Those plural relation blocks 
basic data unit for representing an element attribute data indicate the attribute data objects which hold relations 
object in the preferred embodiment of attribute file 600. SO of which the represented element is a referent data 
Element block 602 preferably includes one element object. The details of plural relation blocks are div 
header block 604, one or more relation sub-blocks 606 cussed below. 

(optional), and one or more "held** element sub-blocks Relation sub-block 606 and "held" element sub-block 
608 (optional). Information regarding the number and 608 of object block 602 (shown in FIG. 8) are prefera- 
type of contiguous sub-blocks in element block 602 35 bry contiguous sub-blocks which are also contiguous 
following element header block 604 is preferably pro- to element header block 604. For each object block 
vided in dictionary file 700 or through the use of a there may be several relation sub-blocks and several 
compiler. These blocks and sub-blocks are described in "held" element sub-blocks. Relation sub-blocks 606 
detail below. specify referent attribute data objects for singular rela- 

Attribute file 600 also includes plural relation blocks 60 tkms held by the represented element "Held" element 
610. only one of which is shown for simplicity. Each sub-blocks 608 specifies the attribute data objects which 
plural relation block 610 contains data for one or more have a being-held relationship with the represented 
relation data objects representing the non-hierarachtcal dement. The relation sub-blocks 606 and "held" ele- 
relationships in data structure 140. Plural relation block ment sub-blocks 608 for the represented object possibly 
610 preferably includes a plural relation header block 63 appear in mixed order. 

612 and one or more plural relation sub-blocks 614. FIGS. 10A and 10B show block diagrams of the 
These blocks and sub-blocks are also described in detail preferred embodiment of relation sub-block 606. Rela- 
below. tion sub-block 606 preferably contains one of two kinds 
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of information. If relation sub-block 606 is a relation which specify next and previous plural relation blocks 

pointer, then it appears as a longword or RELATION in a selected order of such blocks. The plural relation 

pointer 1000 (FIG. 10A) which specifies either an ele- header blocks in that order are all used by the same 

ment block of a single referent attribute data object or a holder attribute data object 

plural relation block (eg., block 610 in FIG. 8) which in 5 FIGS. 13A and 13B shows block diagrams of pre- 

turn identifies several referent attribute data objects for ferred embodiments of two kinds of plural relation sub* 

the relations held by the represented e l em en t. blocks 614. If the referent attribute data object is an 

Alternatively, relation sub-block 606 may be a element attribute data object other than a string, num- 

NUMERIC/STRING identifier for identifying a nam- ber, or then, RELATION pointer 1300 is a long- 

ber or date, or a string. If relation sub-block 606 is a 10 word which pints to the element block for that attribute 

numeric or date identifier, then it appears as double data object If the referent attribute data object is a 

longword. Identifier 1050 may be a pointer to an ele- number or date or a character string, then NUME- 

ment block representing an attribute data object for a RIC/STRING field 1310 is used to point to a floating 

character string or may itself be an integer ox floating po m t number, or date, or a block r e pr e se nting a charac- 

point constant or a date. 15 ter string. 

FIG. 11 shows a block diagram of the pr e fer red em- Creation and use of element block 602 and plural 
bodiment of "held" element sub-block 608 shown in relation block 610, according to the teachings of the 
FIG. 8. Sub-block 608 includes longword pointers 1100, present invention, are described in further detail below. 
1110 and 1120. Longword or FIRST pointer 1100 iden- ^ ^ QOW ^ readily appreciated, the data structure 
tifies an element data block of the first in a selected 20 representations for attribute file 600 discussed above 
order of attribute data objects which have a being-held embody the principles of an Attribute data model ac- 
relationship with the represented element If only one cording to this invention- 
attribute data object has that relationship, then FIRST ^ content9 ^ structure of an instance root block 
pointer 1100 identifies that attribute data object. Long- m shawn m FiGm 14v -instances" of an element type 
word or LAST pointer 1110 identifies the last m the 25 ^feT to a set of attribute data objects all having the same 
selected order of such attribute data objects, but also elcmcnt type and all having the same holder attribute 
identifies the first attribute data object if orJy one held ^ objecTlt has been determined that such groups of 
object exists- The ^^«^^ ato ^^^ attribute data objects are referenced often. Thus, the 
jectshavmga bong-held relatoonstup ^therepre- ^ block was dcvclopcd to prov ide an effi- 

* *f i ^J^%^J^Z£ cient mechanism to access such attribute data objects. 

PREVIOUS pointers of those "held' attribute data ^ ^ ^ ^ attributc ffle ^ 

objects. . . . ,™ A . . * allows it to be dynamically updated more easily than if 

As explained above, plural relation blocks 610 pro- w ^ ^ ludtt ^ SIZE field 1413 anda CLASS field 

vtoandfident mea^ Preference when several refer- 1416 ^***g Wl^^ of longwoods 

ent at^bute data objects must be klentified. Each plural m "f Mock 625 and that block 625 is an instance root 

relation block 610 includes a plural relation header 40 Dl «*. . , . r7T1>5rr . 

block 612 and one or more plural relation sub-blocks. r «* *Z ^ 

FIG. 12 shows a block (Lgram for plural relation LAST pointers 1420 and 1430, respectively, which 

header block 612 accortogtot preferred embodiment ^J^^^J^^^Ti^^ 

of the present invention. Rural relation header block Preferably, pointers U2D, and 1430 testify the locations 

612 comprises longwords 1200. 1210, 1220 and 1230. 45 of the dement type blocks (A*^ in a ^ section in 

Longword 1200 includes a USE field 1203, an relation to dictionary file 700) of those attribute data 

ENTRIES field 1205, a SIZE field 1207, and a CLASS ^i*** 3 - ^ v . „ An . . t , 

field 1209. USE field 1203 indicates the last one of the An INDEX pointer 1440 of block 625 pomte to an 

plural relations sub-blocks 614 for header block 612 *dex directory block (described m detail below) in 

which may contain a valid pointer. ENTRIES field 50 attribute file 600 which permits ready access to each 

1205 contains the number of contiguous plural relation instance of the linked list of attribute data objects, the 

sub-blocks 614 following header block 612 which are first and last object of which are specified by pointers 

included in plural relation block 610; whether those 1420 and 1430 of instance root block 600. 

sub-blocks contain pointers or not SIZE field 1207 and (2) Dictionary File 

the CLASS field 1209 mdtratr, respectively, the mmv- 55 ^ 

ber of longwords in plural relation block 610 and that FIG. 15 shows a block diagram of a preferred em- 

this header block is a plural relation header block. bodiment of dictionary file 700. In the preferred em- 

BIT MASK field 1230 contains bits mdicating which bodiment, the portions of the common database struc- 

sub-blocks 614 contain valid pointers. Thus, although ture in dictionary file 700 include an apex block 702, 
the USE field indicates the largest numbers of contigu- 60 other context blocks 704 and 706, element type blocks 
ous sub-blocks which may have valid pointers, not all of 710 and 712, attribute type blocks 714 and symbol table 

those pointers may necessarily by valid. BIT MASK 716. 

field 1230 supplies this latter information. Apex block 702 is a special kind of context block 

Plural relation blocks are linked in a manner similar which represents the apex data object According to the 
to the linkage of element blocks for attribute data ob- 65 basic rules of the Attribute data model of the present 
jects having the same holder attribute data object Ac- invention, the apex data object holds contexts or attri- 

cordingly , header block 612 includes NEXT and PRE- bute data objects, but is not itself held by any context or 

VIOUS longword pointers 1210 and 1220, respectively, attribute data object. 
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Context blocks 704 and 706 are used to represent a invention, entry into the preferred embodiment of the 

context such as CPU 420 described in connection with data structure through the apex or context requires 

FIG. 4. Element type blocks 710 and 712 each represent access to the information stored in the apex or context 

a different type of attribute data object in attribute rile blocks in dictionary file 700. In different embodiments 

600. Preferably, for each different type of attribute data 5 according to this invention, access through a dictionary 

object there is a corresponding element type block. file would not be required. 

Attribute type block 714 includes information regarding FIG. 17 shows a block diagram of a preferred em- 

the type of relations which exists between attribute data bodiment of an element type block such as element type 

objects of a specified type and referents for these attri- blocks 710 or 712. For purposes of this description, 

bute data objects. Symbol table 716 contains identifiers 10 element type block 712 alone will be described with the 

for the apex, contexts, element types, and attribute types understanding that element type block 710 has the same 

represented in the different blocks of dictionary file 700. components. 

As explained above, apex block 702 and context For each type of element in attribute file 600, there 

blocks 704 and 706 are preferably stored in dictionary exists an element type block 712 in dictionary file 700. 

fDe 700 because dictionary file 700 is usually a read only IS In the preferred embodiment the creation of an 

file. Apex block 702 and context blocks 704 and 706, of a certain type in attribute file 600 must be preceded 

which are very similar and will be discussed together, by a declaration that elements of that type may exist, 

are generally not modified and thus are primarily for a The mechanism for representing the existence of ob- 

read only file. jects of a specified type is element type block 712. 

FIG. 16 shows a block diagram for the basic structure 20 Element type block 712 contains general parameters 
and contents of the preferred embodiment of either apex for certain element blocks in attribute file 600, for exam- 
block 702 or context blocks 704 or 706. Because of the pie, information regarding the length of those element 
qimilimtif* of apex and context blocks, only the file blocks and information regarding the instances of a 
structure for context blocks will be discussed with the given element type. 

understanding that the file structure for apex blocks is 23 The contents and structure of element type block 712 

similar , are as shown in FIG. 17. Included in element type block 

In context block 704, longword 1600 includes a SIZE 712 is longword 1700 which has SIZE field 1703 and 
field 1603 and a CLASS field 1606. SIZE field 1603 CLASS field 1706. As in the case with other data 
indicates the number of longwords of context block 704, blocks, SIZE field 1703 indicates the number of long- 
ami CLASS field 1606 indicates either that the block is 30 words in element type block 712 and the CLASS field 
an apex block or a context Nock. indicates that block 712 is an element type block. 

Longword or NAME pointer 1610 identifies an entry Longword or NODE FORM field 1710 indicates 

in symbol table 716 (see FIG. 14) specifying an tdenti- whether attribute data objects of the type specified by 

fier for the apex or other context represented by block element type block 712 have a predetermined order and 

704. 35 whether the elements of this type are held by a context 

Longword or FIRST CONTAINED CONTEXT or held by other elements. Longword or NAME 

pointer 1620 points to the first context block of a set of pointer 1720 points to an entry in symbol table 716 

contexts which are held by context block 704. Pointers having a name or identifier for attribute data objects of 

1630 and 1640 described below, are empty in apex block this type. INSTANCE LENGTH field 1730 specifies 

702. 40 the length of an element block 602 for attribute data 

For context block 704, Longword or NEXT pointer objects of the type specified by block 712. 

1630 points to the next context in the ordered set of As indicated above, element type blocks for types of 

contexts just described. Longword or HOLDER attribute data objects contained by (Lc.. in the contain- 

pointer 1640 points to the context block or apex block ment tree for) the same context are preferably orga- 

of the context or apex which holds the context for block 45 nized into ordered sets. In fact, these blocks are prefera- 

704. My linked using longword or NEXT pointer 1740, 

Longword or FIRST OBJECT TYPE pointer 1650 which specifies the next element type block, 

points to a first one of an ordered set of element type Longword or CONTEXT pointer 1750 points to the 

blocks, eg., blocks 710 or 712. The element type blocks context block or apex block in which elements of the 

in that ordered set represent element types of attribute 50 type specified by block 712 are contained. Longword or 

data objects held by the context represented by context INSTANCE pointer 1760 points to an instance root 

block 704. The ordered set is preferably a linked list as block in attribute file 600 which contains pointers af* 

explained below in the description of element type fording access to each of the instances of an dement of 

blocks. this type in attribute file 600. The remaining field of 

Longword or FIRST SYMBOL pointer 1660 identi- 55 element type block 712 includes longword or ATTRI- 

fies an entry in symbol table 716 which is designated as BUTE pointer 1770. ATTRIBUTE pointer 1770 points 

a first symbol for the first of an ordered set of symbols to the first relation type for relation types contained by 

for other contexts, objects or relations held by the con- tins element type. 

text represented by block 704. Dictionary file 700 also provides a mechanism for 

Preferably, the apex data object or a context attribute 60 specifying the types of relations which may exist be- 

data object provides the first or top portion of a contain- tween attribute data objects of a type specified by an 

ment tree. Access to an attribute data object of aspect* element type block 712 and their referent attribute data 

fied element type in a context may be obtained by enter- objects. This mechanism includes attribute type blocks 

ing the containment tree through the apex and by pro- such as block 714 (see FIG. 15). 

ceeding through the tree to the the context in which the 65 FIG. IS shows a block diagram for attribute type 

desired attribute data object is found. Because the apex block 714 according to a preferred embodiment of the 

and contexts are represented by apex and context blocks present invention. Attribute type block 714 includes 

in dictionary file 700 in the preferred embodiment of the longwords 1800, 1810, 1820, 830, 1840, 1850 and 1860. 
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Longword 1800 contains SIZE field 1803 and CLASS values to which certain leaf blocks correspond. The 

field 1806 which indicate, respectively, the number of branch blocks are organized to provide a unique path- 

longwords in block 714 and that block 714. way from the root block through one or more middle 

Longword or REPSTYLE field 1810 indicates the branch blocks to a single leaf block having a corre- 

manncr in which relations for attribute data objects are 3 spending set of key values for which the unique path- 

to be specified. According to the p r e f er r ed embodiment way exists. By organizing the root, middle branch and 

of the present invention, relations between attribute leaf blocks in such a manner, the leaf block having a 

data objects and their referent attribute data objects corresponding set of key values, which includes a key 

may be specified either directly or indirectly. For di- value for a desired object can be located expeditiously, 

rectly specified or «gHi*r relations, a relation sub- 10 in turn, the pointer to an attribute data object having 

block 606 (see FIGS, 7 and 10A) in the element block that key value as its key value can be quickly located, as 

602 contains the pointer for a referent attribute data can the attribute data object itself, 

object For indirectly specified or plural relations, a The root branch, middle branch, and leaf blocks of an 

plural relation sub-block 614 of a plural relation block mdtx are preferably represented by index branch 

610 (see FIGS. 8 and 13) accessed from the object block 15 blocks. FIG. 19 shows an index branch block 810 which 

602 for the referenced object contains pointers to the comprises an index branch header block 820 and several 

referent attribute data objects. index branch sub-blocks 830. 

Longwood or NAME pointer 1820 of block 714 FIG. 20 is a block diagram of an index branch header 

points to an identifier entry in symbol table 716 for block 820. In the preferred embodiment, branch header 

attribute type block 714, Longword or OFFSET field 20 Wock g£) jncfodea longwords 2000, 2020, 2040 and 

1830 contains an offset from the beginning of an element 2060. Longword 2000 includes a BRANCH KIND field 

block 602 for a relation sub-block 606 representing rda- jqq^ a g^y VALUES field 2008, a SIZE field 2012, 

dons of this type, or an offeet for a held element sub- ^ a CL aSS field 2016. 

block 608 representing elements of this type, BRANCH KIND field 2004 specifies whether index 

Attribute type blocks 714 for a given element type are 23 branch block 810 is a root middle branch, or leaf block, 

linked by means of a NEXT pointer 1840 m the manner A KFY VALUES field 2008 indicates the number of 

described above for other linked blocks. Umgword or . vaJucs 8pedfied m sub-blocks 830. SIZE field 2012 

HOLDER pointer 1850 points to the etement type CJ ^ SS ^ ^3^^ ^ num . 

block 712 for *"^ d ** S^tS n beroflongwordsmbran^ 

™* *• ^l^^p^p^ y ^p U ^ 30 is an ino^taanch block. 

™ L°^word Different index branch blocks 810 having the same 

1860 also points to an demerttt* Uo*. but thatele- XniJikb]ockm Unked through longword or NEXT 

meat type block » jme^>ec^ ^^J^^ Jointer 2020 and longword or PREVIOUS pointer 

em attribute ^^^^ „ 2uXwhich point to donated next and previous 

block 714 corresponds to a relation. 35 h]ock ^ Qt ^ samc 1 ^ respectively. Long- 

(3) Index File word or TRUNK pointer 2060 points to the trunk block 

Index file 800 provides another efficient and direct for T ^ ^ ^ h b ^f^ 
means to access attribute data objects winch share a ln t tt ^J n ^ d ^ bodiment * mde ? branch header 
£n£m holder attribute data object. Specifically, 40 Wock » . fbUowed ccnoguously by one or more 

index file 800 provides a means for accessing certain "^^T^^r^^v. ^ cK _ * PTr 

ones of the attribute data objects to which unique key J^i^ ^^J^J"^ 

i, BW h~-n ««i™H preferably mdude a longword or KEY VALUE 

^r^ ^^LncnU index file 800 com- pointer 2100 - • toygw^d or ^/OBJECT 

pr^^e^dex branch blocks organized into at 45 Pointer 215a KEY V/O-UE pointer 2100 specifies a 

leasTone index having a tree structurT^* branch U *^* t ^^™^?^ T PAP 

blocks of an index include leaf blocks each of which *^*>* ™» * " " 

corresponds to a different set of the key values. Each /OBJECT field ******** * an ^en^lock «°2 for 

key value for an attribute data object is in only one of ™ attnbiitj^c^ectm attribute file 600 having the 

the different sets of key values and, 50 key value deaoted by the correspondmg KEY VALUE 

leafblockhasacorr^ ^ ^^J^^TT 

the attribute data object to which that key value is branch block 810 is a branch block, the LEAF/OB- 

^/^j J JECT field 2150 points to a branch block in the unique 

iSblocks include pointers, each of which cone- pathway to a leaf block, the set of key values of which 

sponds to a key value of the leaf block and to the loca- 55 are within the group of sets for that branch block, 

don in attribute file 600 for the attribute data object In the preferred embaliment, each index branch 

having the key value as its assigned key value. Quick block 810 is used either as an ordering index or as an 

accessing of a desired attribute data object b achieved accessing index. The ordering index is used to insert 

by entering an index with a key value for the desired elements into a list according to prescribed ordering 

attribute data object, and by locating a unique pathway 60 rules and enables quick access to the place in the list of 

through the tree structure of the index to the leaf block elements, eg., as described by an instance root block 

having that key value and the corresponding pointer to 625 or a held dement sub-block 608. An accessing index 

the desired attribute data object is used to access existing elements quickly using a key 

Accordingly, in the preferred embodiment an index's value, 

tree structure includes a root block to provide an entry 65 In the preferred embodiment of the invention, both 

into the tree structure. The root block "branches" to a the ordering and accessing index require use of index 

plurality of branch blocks each of which corresponds to directory block 630, discussed briefly with regard to the 

a different, non-overlapping group of the sets of key constituents of attribute file 600 (see FIG. 7). A block 
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diagram of index directory block 600 is shown in FIO. an existing element type Wock 712 for the new element 

21 (Step 2310). 

Index directory block 630 includes longwords 2210, Once the instance length is determined, primary 

2290 and 2270. Longword 2210 includes SIZE and memory is checked to see whether storage space is 

CLASS field 2230 and 2240, respectively, which indi- J available for element block 602 (Step 2315). If storage 

cate the number of longwords in index directory block space does not exist, thm primary memory space for 

600 and that block 600 is an index directory block. that dement block is created (Step 2320). The details for 

Longword or ORDERING pointer 2250 identifies the managing storage space by CPU 110 m permanent and 

instance root block for an ordering index, and longword primary memory is described m more detail in a later 

or ACCESSING pointer 2200 indicates a root branch W section and involves virtual memory and mapping tech- 

block for an accessing index. niques readily ascertainable to artisans of ordinary skill. 

Z&d&XSXiSSZ - SHE? tt&ZZXSRSS 

atttfcute data object, held by a ^pointer "^^SSmSdm object is chosen for the 

1440 of an msUn~ root ^ new^ement^h that a bei^g-heW relationship exists 

directory Wock 630 so that attribute For attribute dau ^ . holder attribute data 

objects heW by another attribute dau objec^nc^ ££^ Stcp 2335). Selection of the holder attribute data 

^^Z^J^L tJ??"* SSiv^a ^ obS i FIRST, LAST and INDEX pointers, 

pointer 1120 of Uie Tidd" object « apeofr- u^UlO and 11% respectively, in "held" object 

mg designated first and last ones of the held objects. ^Moc* 608 of element Mock 602 for the holder attri- 

The accessing cjperations are explained m gra^ bute data object to be located (Step 2335). 

Ma ™- 25 FIRST, LAST and INDEX pointers 1100. 1110 and 

D Basic Database Operations 11% respectively, may be updated then to reflect the 

M . m . . existence of the new element as an element now held by 

Using the preferred embodiment of the invention, ^ attribute ^ object of course, updating 

certain basic data operations such as creation, erasure. these fields is not necessary if the new element is not the 

and access, can be easily and efficiently carried 30 first or last element held by the holder attribute data 

according to preferred methods described below. The object 

following description presumes that, whether by use of A ^ the sub-block 608 pointers, NEXT, 

a compiler or dictionary 700, certain data like an apex or PREVIOUS, and HOLDER pointers 925, 940 and 930, 

the contexts which are necessary to the creation of respectively of element header block 604 in element 

attribute data objects, already exist in common data 3J block 602 of the new attribute data object are used to 

structures 140 or 140'. It is also assumed that the ele- link the new element to the element blocks for the other 

ments and relations to be created and the element types elements having the same holder as that new element 

and relation types for the elements and relations to be ^ indicates the holder attribute data object for the 

created have already been specified to data structure ^ element (Step 2340). This is done by locating 

140, so that the appropriate element type blocks and 40 HOLDER pointer 930 in object header block 604 for 

referent type blocks have already been created. the new object. That HOLDER pointer 930 points to a 

tt\ m_~~.» r-~**i™ memory area in which an element Wock 602 for the 

{l) fciement ureanon holder attribute data clement of the object being created 

FIGS. 23A and 23B show a flow diagram 2300 for a may be found. In addition, element pointers to other 

preferred method of creating an element data object 45 attribute data objects which have the same holder attri- 

("new element") according to the present invention. As bute data object as the new attribute data object are 

stated above in connection with the description of appli- provided as NEXT pointer 925 and PREVIOUS 

cation programs 132 and 134, these programs either pointer 940. If the new element is the only attribute data 

contain the information needed for forming common object held, no pointer will be provided in a NEXT 

data structure 140 in memory 120 or have their data- 50 pointer 925 of element header block 604 and no object 

bases alrady organized in accordance with the Attribu- pointer will exist as PREVIOUS pointer 940. 

tive data model of mis invention. Next, the FIRST, LAST, and INDEX pointers 1100, 

If the application program databases need to be con- 1U0 and 1120, r espectively, on the "held" element 

verted to the Attributive data model of this invention, sub-block 608 of the holder attribute data object, which 

the information needed from these programs to create 55 have been previously located, are updated to reflect the 

an element is in the form of "node data." Attribute dau existence of the new element and to reflect its "being- 

objects to be created may correspond to node data from held relationship with the holder attribute data object 

the application programs or may be specifically derived (Step 2345). With regard to such updating, if the new 

for creation. Accordingly, creation of an element data object is the first attribute data object held by the holder 

object may involve the extraction of node data from an 60 attribute data object, then a pointer to the element block 

application program and a determination of the type of 602 of the holder attribute data object will be provided 

corresponding element data object to be created from in the FIRST pointer U00. INDEX pointer 1130 will 

the node data. (Step 2305). Examples of such extraction alBO be updated to identify an index directory block 630 

appear in the next section. if appropriate. 

Once the type of the new element has been deter- 65 To complete the creation of the new element in 

mined, the instance length, that is the length of element method 2300, other fields of element block 602 must be 

block 602 for the new element, can be determined by initialized. For example, TYPE DEFINITION pointer 

reference to the INSTANCE LENGTH field 1730 of 920 of element header block 604 for the new attribute 
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data object must be provided with appropriate pointers, If none of the scanned plural relation sub-blocks 614 

such asapointer to the dement type block 712 in dktio- arc free (S^ 2450) then a plural relation block which 

narv file 700 which specifies the type of the new ele- contains a free phiral relation sub-block 614 is allocated 

meat "Held- dernenHub-block 608 and relation sub- (Step 2455), A sub-block is free if it does not contain a 

block 606 attribute data object comes to hold or conies 5 valid pomter to an object block 602for a data 

to have relations with other attribute data objects. object The newly allocated plural rdaUon block 610 is 

lWMVU * lu^ed ^th the other phiral relation blocks 610 for 

(2) Creating a Relation the new object (Step 2460). 

The steps shown in FIGS. 23A and 23B are sufficient After tte ^tionand linking of a new plural rela- 

for Son of an dement data object To create a rela- 10 tions block 610, or if a free sub-bUxk in one of the linked 

Sn^Sjecradd^l steps are^eded. FIGS. 24A relations block 

2»B show a flow char?2400 depicting the steps «^ ob £j U fi^^J^^^A 

involved in creating a re^n between the new dement tg^^^U ^^ m ^ 

^ Tf™ tlSSl 13 oWnS £ pomter foTthe referent is placed 

^node data ^^^ a V^^^T into one of the plural relation blocks 610. That block 

database may a 610 is the one accessed from the REFERENCES 

the rdation may be formed by computations Permed mter ^ eIment b]ock 604 for the dement 

by one of the application programs. Thus, a node data ^ m q{ ^ attribute ^ object (Step 

descriptor from one of the application programs can be 2475> 

extracted for use in creating a relation attribute data } 

object This for extraction function is described in (3) Relation Erasure 

greater detail below. When extracting the node data ^ scctioo dtsCiibeA erasure of all relations of a 

descriptor, the appropriate attribute data object to be ^ven type held by a given dement Rdation erasure 

the referent attribute data object for the relation data ^ jj^^ fr^g ^ 0 f 3^ used to hold the 

object is selected. pointers which relate an attribute data object to its ref- 

Once the extraction and selection are complete, the mnt attT a )Ute ^ object FIG. 25 shows a flow chart 

relations sub-block 606 in the proper dement block 602 2500 depicting the steps involved in the preferred 

is then identified (Step 2405). From the position of the method of erasing a relation. 

relation sub-block 606 in dement block 602, the nature 30 Firs ^ ^ relation sub-block 606 used to relate the 

of the relation between the holder attribute data and the relation's holder attribute data object and referent attri- 

referent attribute data object (Le., plural or singular) can bate ( | ata 0 tyect is located (Step 2505) using the OFF- 

be determined (Step 2410). SET 1830 of the rdation type. 

If the relation is singular, a pointer from the holder Next, a determination is made, according to the rela- 

attribute data object to the referent data object will be 35 tion type, whether the relation is singular (Step 2510). If 

provided in relation sub-block 606 of the dement block ^ ^ rdation blocks 610 specified in the REF- 

for the corresponding dement If the relation is to be ERENCES pointer 935 of the referent's dement block 

plural, a pointer to a plural relation block 612 will be 602 are scanned to find the object pomter to the holder 

provided in that relation sub-block 606. A referent attribute data object for this relation (Step 2515) when 

pointer to the referent data object will then be provided 40 ^ type is not numeric, a date or a string. Then the 

in the plural relation block 612 identified by the pointer object pointer to the holder attribute data object is 

in the element block 602 far the corresrxrading dement cleared from the plural rdation block pointed to by the 

If the new relation is singular, a determination must REFERENCES pointer 935 of the referent's element 

be made whether the rdation sub-block 606 (see FIGS. block 602 (Step 2520). Finally, sub-block 606 in the 

8, 10A and 10B) of the bolder attribute data object 45 holder attribute data object which contains a pointer to 

already contains a pointer (Step 2420). If this is also the referent attribute data object is cleared along with 

true, creation of the rdation will be temporarily halted any string data pointed to (Step 2525). 

while a previous relation specified in relation sub-block if the relation to be erased is not a singular relation, 

606 is erased so that a new singular relation can be then plural rdation blocks 610 of the holder attribute 

created (Step 2425). When relation sub-block 606 does 50 data object are scanned unless the referent type is nu- 

not contain a pointer to a referent attribute data object, meric, a date or a string (Step 2530). The purpose of the 

then a object pointer to the referent attribute data object scanning is to locate the plural relation blocks 610 ac- 

for this relation is obtained and placed in relation sub- cessed by the REFERENCES pointer of the element 

block 606 (Step 2430). block 602 for the indicated referent attribute data ob- 

If the relation to be created is not singular, then a 55 jects those referent attribute data objects are the ones 

plural rdation block 610 is allocated for specifying the pointed to by the referent pointers in those plural rela- 

new rdation data object unless one has already been tkm blocks 610 of the appropriate type for the holder 

allocated (Step 2435). A pomter to the plural relation attribute data object of the rdation to be erased (Step 

block for the new relation is then placed into the appro- 2535). Next, the plural relation blocks 610 accessed by 
priate relation sub-block 606 (Step 2440). 60 the REFERENCES pointer 935 of those referent attri- 

Next, the plural relation sub-blocks 614 (see FIGS. 8, bute object blocks are scanned to find a pointer to the 

13A and 13B) of the allocated plural rdation block 610 holder attribute data object (Step 2540). 

are scanned as well as plural relation sub-blocks 606 in When the pointer to the holder attribute data object is 

other phiral rdation blocks linked to the pointed to found in a phiral relation block 610, the holder pointer 
plural relation block 610 (Step 2445). As described 65 to the referent attribute data object is rendered inopera- 

above, plural relation blocks 610 are linked by means of tive by resetting the corresponding bits in BIT MASK 

NEXT and PREVIOUS pointers, so scanning prefera- field 1230. That BIT MASK field 1230 is found in the 

bly proceeds using those pointers. plural relation header blocks 612 for the plural rdanon 
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blocks 610 in which pointers to the holder attribute data lively called attributes) to be fetched. The given ele- 

object pointer are found. Finally, the space for plural ment(s) will be referred to as the holders), 

relation blocks 610 which were scanned is reclaimed The first determination to be made upon entering 

along with any string data pointed to and the relation flow chart 2700 is whether the relations for a holder of 

sub-block is cleared (Step 2545). 5 a given type are singular or plural (Step 2705). If singu- 
lar, the next determination is whether there is a first or 

(4) Element Erasure next holder of the elements) or relations) to be ac- 

FIG. 26 shows a flow chart 2600 describing the steps cessed (Step 2710). If there is no such holder, then a 

by which an element object is erased. After this element completion indicator is set (Step 2715), indicating that 

is accessed, plural relation blocks 610 for the object 10 the search for all the holders is complete, and the execu- 

being erased are obtained from REFERENCES pointer tion of the access routine is ended with a return of no 

935 for the element to be erased (Step 2610). result (Step 2720). 

Next pointers to this element are erased from the If there was a next holder, the offset field (e.g., 1830 

plural relation blocks under the elements accessed from shown in FIG. 18) from the attribute type block is then 

those plural relation blocks (Step 2620). 15 used to find the offset from the start of the holder's 

After erasing th r?r pointers, all singular and plural element block to find a pointer to any element block for 

relations held by the element are erased (Step 2640) and the relation or element desired (Step 2723). The element 

space used by any plural relation blocks associated with block of that next holder is then retrieved by using the 

this element is also freed (Step 2650). All element blocks virtual address from the address table in the common 

held by the element are erased by recursive use of this 20 area of memory 120 (Step 2725). Next, a aetermination 

procedure. Elements or objects held by this element are must be made to see whether there is a relation or held 

then erased (Step 2655). Next, indices pointed to by the element for this particular holder (Step 2730). If so, (i.e., 

INDEX pointer 1120 in the element block for the ele- if the appropriate pointer is not zero), then the virtual 

ment being erased are freed (Step 2660). The element address for the attribute type block of the desired attri- 

block for the element being erased is from 25 bute is examined to access that attribute (Step 2735). 

element blocks for the other elements having the same When there is a non-zero pointer, the information about 

holder (Step 2670). Finally, space for the element is the desired referent or held element is returned (Step 

reclaimed (Step 2680). 2745). 

If the appropriate pointer is zero (Step 2730), then 

(5) Accessing an Attribute Data Object jq tl|ere ^ ^ ot element of the required type in 

From the organization of the preferred data struc- the element block of the next holder attribute data ob- 

tures described above, as well as from the preferred ject In this case, if a plurality of holders is specified, 

methods for creating and erasing elements and relations then a search continues either until a holder is found 

also described above, different ways of accessing ele- with a relation or an element to be returned (Steps 2710, 

merits and relations will be apparent to persons ofordi- 35 2723 and 2725), or until there are no more holders 

nary skill in the art. Accessing, of course, depends upon (Steps 2710, 2715 and 2720). 

the type of information desired, and the data structure If, in the initial deter minati on, the attribute type was 
provided in the preferred embodiment show pathways found to be plural (Step 2705), then a determination is 
for such accessing. made whether execution of the access is first commenc- 
FIGS. 27A and 27B show a flow chart 2700 describ- 40 ing (Lc, is the examination of the entire expression com- 
ing a preferred method of accessing common data struc- mencing) or at least commencing examin a tio n of a new 
ture 140 or 14ff to find either the elements having a holder element (Step 2750). If so, then as with the single 
being-held rdationship with a given element or to find attribute type, the next determination is whether there is 
referents of certain relations of that element The proce- some next holder (Step 2751). If not, the completion 
dure reflected by flow chart 2700 may also be used to 45 indicator is set (Step 2755), and a return is made with no 
obtain held elements and referents of relations for multi- results (Step 2760). 

pie attribute daU elements. The described method is not If there is a next holder, then the element block for 
the only such method, but it is provided as illustrative of that next holder is retrieved (Step 2763), and a determi- 

the types of methods which can be used to carry out the nation is made from that element block whether there is 

purposes of this invention. 50 a relation block 610 or a first held element for the next 
Flow chart 2700 assumes that during the creation of holder. This can be determined by examining the ele- 

the common data structure 140, a compiler or some merit block for the next holder (Step 2766> If no attri- 

similar sort of N "ff"*g^ processing software (included bute exists for the next holder, then subsequent holders 

in converter p rogr ams 540 and 570) generated a virtual are obtained and cxnmmrd until either a holder is ob- 

address or offset for identifier. The flow chart 55 tained which has an attribute (Steps 2751 and 2763) or 

further that common data structure placed that until there are no more holders (Steps 2751, 2753 and 
virtual address or offset in an address table located in a 2760). 

common area of memory 120 so U could be accessed by From the attribute type block, a deter minati on is 

retrieval programs, such as retrieval programs 580 and made whether those attributes are relations (Step 2773). 

590 shown in FIGS. 5A and 5B. Those retrieval pro- 60 If so, then the next relation is retrieved from the corre- 
grams arc preferably interpreters, ut they could also be spondmg plural relation block (Step 2776). Associated 
any other type of language processing software, such as with the access of this plural relation block is a "place 

compilers. indicator'* which keeps track of the next one of the 

Flow chart 2700 also assumes that prior to its execu- relations from the plural relation blocks to be accessed, 

tion, a virtual address for nrey—fog a referent or held 65 This is done because the routine in flow chart 2700 only 

element of the given element has already been retrieved returns one result in each access. When the last relation 

as have the virtual addresses of the attribute type block from the plural relation block 610 is obtained, the "place 

714 corresponding to the relations or elements (coUec- indicator" directs that the next inquiry into the exis- 
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tence of a relation or an element to be obtained be an- cases application programs may already use attribute 

swered in the negative. Each time a relation is obtained, data objects organized in accordance with the present 

the "place indicator** is updated to the next position, invention. .., 

and a return from the procedure is made with the inch- The process of extraction and conversion refers to 

cated result (Step 2780). 3 the methods by which data from application program 

If the desired attributes were instead found to be databases are converted to the common data structure 

elements or if the examination was not commencing 140 (or 14C). As shown in FIGS. 5A and 5B ( converter 

(Step 2773), then a deterrnination would be made programs 540 and 570 take data from the application 

whether that element was the first in a linked list of databases and convert that data from the format in those 

elements having a being-held relationship with the 10 databases into a format proper for common data struc- 

holder (Step 2783). If not, then the next held element is ture 140 (or t40> 

obtained using NEXT field 925 from the element ac- There are several ways to organize a common data 

cessed immediately prior to the present element (Step structure according to the present invention for each 

2786). A different "place indicator** which keeps track application program database. The organization and 

of the next associated one of the elements to be accessed 15 conversion of the application program data for the the 

is updated to point to the next of the held objects. The common data structure likely depends upon the con- 

return is then made with indicated result (Step 2780). tents of the data in the application program database, as 

If the desired element was the first of the held ele- well as upon the anticipated usage of the common data 

ments (Step 2783), then the held object block is obtained structure. 

using the offset pointer and the holder attribute data 20 Organization of the common data structure, and con- 
objects element block, and the appropriate place indi- sequently extraction and conversion, need not follow 
cator is initialized (Step 2790). The return is then made absolute and unwavering rules. Instead, this section 
with the indicated result (Step 2780). contains some general guidelines and design consider- 

FIG. 28 shows another example of an access proce- ations for persons desiring to practice this in vention, 

dure. The flow chart 2800 in FIG. 28 is used for finding 23 Additional guidelines and design considerations will be 

an attribute data object using the index file 800 and a apparent to person* of ordinary skill in the art, without 

key value. Again, it must be remembered, that flow undue experimentation, from the entire description of 

chart 2800 is only one method of access and is not meant the preferred embodiment such as the construction of 

to limit the invention. the preferred data structures and the preferred methods 

When using a key value to identify and find an attri- 30 of access, creation, and erasure, 

bute data object, the index directory block (see index Quite often, the first concern in building a common 

directory block (30 in FIG. 8) b searched for that key data structure according to this invention is the selec- 

value (Step 2810). If that key value is not found (Step tion of e lem e nt data objects. The information in the 

2820), then a return is made from the routine in FIG. 28 application program from which element data objects 

with no result (Step 2830). 35 are often selected can be referred to as node data. Node 

If a key value is found, then an index result block data generally includes "things" that are either M ob- 

2890 shown in FIG. 28A is created with four longwords jects" or -subjects" in the database. In terms of parts of 
set to the following values (Step 2840). First leaf node speech, therefore, element data objects are most likely 

2891 is set to the pointer of the leaf index branch block data that would be described by nouns. For example, 
810 coirtaining the first occurrence of the desired key 40 node data can include physical objects, such as circuits, 
value. First leaf index 2892 contains the ordinal of the gates, rxjrtions of an engine, or persons. Node data can 
index branch sub-block 830 in the index branch block also include events, such as time line entries or filing 
810 which is the first occurrence in the leaf index dates. Another example of node data are concepts, such 
branch block. Similarly, last leaf node 2893 and last leaf as ideas and colors. 

index 2894 contain a pointer and ordinal, respectively, 45 Once the elements are selected, then the holding 

for the last occurrence of the desired key value. Index relationships between elements are established. The 

result block 2890 is a temporary data structure created determination of holding relationships usually reflects 

only for access using index file 800. some hierarchy among the dements. As with the selec- 

Next, the address of the desired element^) is found tion of elements themselves, the detennination of the 

using index result block 2890 (Step 2850). If the key is SO hierarchy reflected by the holding relationship is, in 
unique, then first and last occurrences are the same. If most cases, not unique. Preferably, the determinauon of 

the key is not unique, as may be the case for the order- the holding re l ati on s h ip should also take into account 

ing index, then die complete set of valid results can be the anticipated use of the data. The existence of a rela- 

found using the index result block 2890 because the tionship between two ele m e nt s (or between an element 

index branch blocks are linked. The pointer to the attri- 35 and a relation) does not necessarily mean that such a 

bute data object is found using the result block. relationship should be reflected as a holding relation- 

If the key value is found, it will contain an address in ship in the common data structure. That relationship 
the attribute data file 600 for a corresponding attribute can also be represented by the nc^-hierarchical relation- 
data object A return from this procedure is then made ship i nd ic a t rd by the relation data objects, 
with the indicated result (Step 2860). 60 The types of relationships winch are most often re- 
flected in the holding relationship reflect some natural 

E. Data Organization, Extraction, and Conversion hierarchy, such as officers of a corporation, or reflect 

In accordance with this invention, the information the constituent parts of a thing, such as the parts of a 
used by application programs such as programs 530 and machine, the chapters of a book, or cities in a state. The 
560 shown in FIGS. 5A and 5B, must be fit into an 63 holding rektionslnps can also reflect the possession of 
organization of common data structure 140 (or 1400- In one thing by another. 

many cases the application programs are previously Once the holding relationships are determined, how- 
written in terms of their own databases, and in other ever, a context must usually be selected. As explained in 
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an earlier section, the context is a construct to help in -continued 

naming attribute data objects since the names of such (7) add m-A: 33ft 

objects have meaning only in the context holding those w add m332 

objects. The context should be used to reflect groupings (9) mtti/si 

of related attribute data objects for convenience of ref- 5 <10) 33033VSZ 

erence and to allow the use of specialized vocabulary. 

For example, design information about printed circuit p^h non-blank line of this file represents a node 

boards might be organized into a different cont ext from datum, line 1 calls for the creation of three-input AND 

design information about VLSI chips, so that terminol- ^ m ^0 Lines 2 through 5 call for the creation of puis 

ogy familiar in either application area can be used with- 10 3x2, 324, 326\ and 328 of gate 320. Line 7 calls for the 

out conflict In the example demonstrated in FIGS. 3 creation of two-input AND gate 130. Lmes 5 and 9 

and 4> the term "gate" can have different meanings in indicate that pin 328 is connected to pin 334 by signal 

these two application areas. The use of separate con- "SL» Similarly, lines 2 and 10 indicate that pin 322 is 

texts allows the same term "gate" to have different connected to pin 336 by signal "S2." 

meaning in each context 15 Converter program 570 could be designed to read file 

One can also have several layers of contexts. For 565 and create common data structure 140 or 140* repre- 

example, a first context may contain objects related to senting the circuit of FIG. 3 using operations described 

general app lic ati on concepts such as version tracking m ^ proceeding sections. Part of the common data 

and project management Each of a plurality of contexts structure so created is shown in FIG. 4. Each of the 

held by the first context might contain attribute objects 20 « t j 1 j n g S « gates and pins or signals) is an element, 

for particular technologies, such as mechanical or elec- holding relationships represent the hierarchy im* 

trical. plicit in the creation — first the AND gates, then the pins 

Relations are usually determined next After the node OT gjguai^ jh c remaining relationships, such as signal 

data are assigned as elements, the information r emaining connections and names, are created as relations, 
usually concerns the relations or attributes of such node 

data which, if not reflected m the hierarchical holding F. Storage Management 
rdatioships, can be thought of as generally reflecting ^ ^ ^ expected, the amount of storage required 
descriptors of the node data. The purpose of die rela- to implement an embodiment according the present 
tions is to reflect non^uerarchical relationships that invention can be quite great This section discusses a 
exist among attribute data objects. The relations are 30 preferred embodiment of a storage management tech- 
created so that they associate the appropriate objects in jaqoc for maintaining , updating and accessing common 
order to reflect the relationships between node data and data structure 140* in order to achieve benefits such as a 
their descriptors as expressed by the original application reduction in the amount of required storage. This pre* 
data. Examples of node data descriptors, preferably ferred embodiment of a storage management technique 
represented by relations, include the,ccnmectkm of is abo designed to provide an easy and efficient means 
gates to signals, the identification of the designer of a ^ accessing and updating the data structure 140/ of 
circuit and the connection of events in a project plan. memory 120 by application programs. 

The final steps of data organization involve type The description of the storage management technique 

determination and selection of key values. The "typing** ^ is based upon the representation of the system shown in 

of an attribute generally follows the designation of ele- piq 93 showing common data structure 140' as includ- 

ments and relations, as well as the designa t ion of hold- ^ a 0 f master data file 515. snapshot data file 525, 

ing relationships. The types generally reflect the sets ^ control file 555 with locks 568 and 5*9. Storage 

into which the elements and relations have already been management software 566 controls the files in common 

greyed and describe the conmron^ ^ data structure 140*. 

or relations in those sets. a block rfia gm m of an embodiment of common data 

The selection of key values depends again on the structure 1W is shown in greater detail in FIG. 29. 

data. The use of key values is primariy an aid to access, RG 29 includes a master data file 2900, which corre- 

so the detennination and selection of the keys should spends to master data file 515 in FIG. 5B. Master data 

follow the anticipated usage of common data structure ^ 2900, shown as including macropages 0-3, corre- 

140 or 140'. In addition, the use of key values may re- 5ponds to ^ most TCCeat version of the common data 

fleet an ordering of the information in the application structure 140'. That most recent version is either the 

programs databases to facilitate use of such information version currently being modified or the one which was 

by the application programs. The details of converter mM rtccntfy modified, 

programs 540 and 570 iifesr^tfic to the remanents 55 ^ HQ . 29 show* each niacror^em 

of application programs 530 and 560, respectively, the 2900 has an associated numbered entry composed of 

following example of the processing , performed by such ^ ^ btf ^ QIimo er of an entry refers to 

converter programs b provided to illustrate the guate- ^ ^^^^^^ptpordonofan 

lines provided above. If an application P*Oj£^ entiyrefersTthe version number. The version number 

generates the circmt shown in nG^fik 5«^IG. j*!*^ a version of the datab« as updated by a single 

SA) might contain the following information descnp- ^ fa accon j ancc ^ ^ preferred embodiment, 

tive of the circuit. newer versions always have a higher number than older 

versions. The total number of macropages depends on 

(i) add 3-i-A; 320; the total size of the database. 

(l) add 32CU22/S2 $5 Snapshot data file 2910 corresponds to snapshot data 

(3) 320-32* file 525 in FIG. 9B and includes several slots 0-5. Each 

(5) mlwst slot contains a macropage and corresponds to one of the 

(6) macropages from either the current version of master 
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data file 2900 or from a previous version of that file. The common data structure \W. the storage management 
macropages from previous versions of the master data software obtains the DBC lock, increments user count 
file 2900 still maintained in snapshot file 2910 are for field 3005, and returns the DBC lock The purpose of 
versions which are still active. A version is still active if the DBC lock in this instance is to prevent multiple 
there is at least one application program or user which 5 users from simulataneously accessing the user count and 
is currently accessing macropages of that version. improperly incrementing it. 

The numbered entries associated with each macrop- Rollback version number field 3010 and rollback 
age in snapshot data file 2910 include as the larger num- version pointer 3015 refer to a rollback function. This 
bera value for the corresponding macropage in master function allows a user to retract certain changes made 
data file 2900, and include as a superscript a number 10 to a version of common data structure 140* . Rollback 
indicating the version of that macropage. occurs only while changes which are being made to 

After master data file 2900 is updated, those macrop- common data structure 140* by a user are still in 
ages from the masterdata file 2900 which were changed progress. Rollback occurs either because the user per- 
are copied into slots of snapshot data file 2910. This forming the changes "voluntarily" decides it does not 
copying accounts for the multiple versions of macrop- 15 want to proceed with the changes and wishes instead to 
ages from the master data file 2900 which are stored in restore master data file 2900 to its state before the modi- 
snapshot data file 2910. The snapshot data file must not fications started, or because an error makes it impossible 
grow indefinitely, so housekeeping routines, which are to complete the changes. 

explained in greater detail below, are invoked to re- In the preferred embodiment, the version being rolled 
move outdated macropages. 20 back is fully modified in accordance with the changes 

Certain of the slots of snapshot data file 2910 are specified by the user. The storage management and 
referred to as a "natural slots.** A "natural slot" refers to updating steps described below are executed, but this 
a slot in snapshot data file 2910 having a slot number to-be-rolled-back version of common data structure 
winch is the same as the corresponding macropage 140' is not made available to other users. Immediately 
number. This is the state of snapshot data file 2910 when 25 after the to-bc-rolled-back version has been created, a 
it originally receives the contents of the master data file new version, the rollback version, is created. The roll- 
2900 This initial state, in which all the macropages are back version, by use of switch blocks in section 2928 
in their natural slots, is desired for efficiency. and snapshot data file 2910, undoes all the changes 

Data Base Controller (DBC) 2920 controls the stor- brought by the to-be-rolled-back version. Accordingly, 
age management functions. DBC 2920 corresponds to 30 after the roll back the master data file 2900 for the rolled 
the control file 555 in FIG. 5B. In general, DBC file back version has been returned to its state before the 
2920 controls the modification of data structure IW as roll back sequence was initiated, 
well as the access to that data structure. DBC 2920 Snapshot data file 2910 is not returned to its state 
controls the modification of data structure 140' by man- before creation of the to-be-rolled back master file 2900. 
aging and keeping track of changes to the data structure 33 After roll back, snapshot data file 2910 contains two 
and by ensuring, through the use of ALTER lock (See additional versions, the "bad version" that was rolled 
FIO. 5B) that only one user can make modifications to back and the new current version As stated above, 
a version of a macropage of the data structure. DBC file however, users are not able to read the "bad version," 
2920 controls access to the data structure by keeping and the new current version is just a copy of the mac- 
track of the location of all active macropages and by 40 ropages initially changed by the "bad version." The 
preventing collisions with certain users through the use "bad version** is already obsolete at the completion of 
of DBC lock (See FIG. 5B). roll back and will be deleted by housekeeping routines 

DBC 2920 contains four major components. One to be described later, 
component is pointer/counter section 2922 which indi- In pointer/counter section 2922, roll back version 
cates where the other portions of DBC 2920 reside. 43 number 3010 refers to the number of the version which 
Another component is HASH table 2924 which pro- is "rolling back" the -bad version" and roll back ver- 
vides a means for locating the active macropages in sion pointer 3015 points to the version block of that 
snapshot file 2910. Version block section 2926 contains version number. 

version Mocks, such as blocks 2930, 294ft and 2950, Next version number 3020 and next version pointer 
which contain information about different versions of 30 3025 in section 2922 refer to the version of common 
data structure 14C. Switch block section 2928 contains data structure 140* which is either currently being up- 
section blocks, examples of which are 2932, 2934, 293*> dated or, if there is no version currently being updated, 
2938, 2942, 2944> 2952, 2954, 2956 and 2958, which which will be the version to be updated next 
contain information about the active macropages. Pref- Current version number 3030 and current version 
erably, different kinds of switch blocks are used for 35 pointer 3035 refer to the most recent version which is 
changes in attribute file 600 and in index file 800. If, currently readable. This is the most current version 
however, the information in attribute file 600 and index which is available in snapshot data file 2910. The oldest 
file 800 resided in a single file, one kind of switch block version number field 3046 and the oldest version pointer 
would be needed. In the ensuing discussion, the discus- 3045 refer to the the active version which is the least 
sion about switch blocks applies to changes either in 60 recent. Field 3040 and pointer 3045 are changed as 
attribute file 600 or index file 800. common data structure *W is being updated and obso- 

FIG. 30 shows a preferred embodiment of pointer/- lete (Le„ inactive) versions are freed, 
counter sections 2922 in greater detail As shown in The initial version number 3050 refers to a version of 
FIG. 30, pointer/counter section 2922 preferably con- common data structure 140* existing at the time an event 
tains a user count 3005 and several other fields and 65 referred to as a "checkpoint" occurs. For purposes of 
pointers. User count 3005 indicates the total number of error recovery, the contents of common data structure 
users which are accessing or modifying common data 140* in master data file 515 are replaced with a check- 
structure 140'. Each time a new user wants to access point This -checkpoint version" may be used to con- 
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tinuc operation of the system after the loss or destruc- recently has been placed back on disk to save space in 
tion of part or all of the data structure 14C contents, the primary memory. It would be inefficient to retrieve 
Initial version number 3050 indicates the newest ver- this macropage from disk merely to update one pointer, 
son in snapshot data file 2910 when the most recent It is instead easier to update the corresponding field of 
checkpoint occurred. 5 version block 3100, since that version block always 

HASH table 2924 provides a means for accessing the resides in primary memory, 
active macropages in a manner described in greater A first attribute switch field 3160 and a first index 
detail below. HASH table 2924 is preferably a standard switch field 3165 point to the switch blocks for the 
HASH Table and thus will not be described in any attribute and indei files, respectively, which were the 
further detail HASH Table 2924 preferably contains 10 first ones created for the corresponding version. Of 
pointers to the switch block corresponding to the most course if the attribute and index files are combined then 
recent version of each macropage. As described below, only one of these fields is necessary, 
each switch block is linked to its earlier versions. Thus, Completing version block 3100 are four version ini- 
by entering through HASH table 2924, a user can locate tial macropage number fields 3170, 3175, 3180, and 
every active version of each macropage in snapshot 15 3185. The initial attribute macropage number field 3170 
data file 2910. Version area 2926 preferably includes a identifies the highest macropage number for the master 
plurality of version blocks 2930, 2940 and 2950 shown data file 2900 corresponding to attribute file 600 at the 
in FIG. 29. Each one of those version blocks preferably start of that version. For the example in FIG. 29, the 
contains the fields and pointers shown in version block number in field 3170 would be 3. The initial snapshot 
3100 of FIG. 31. 20 macropage number field 3175 contains the highest mac- 

Version block 3100 includes a version number field ropage number in snapshot file 2910 for attribute file 
3110 which kfcnfifi** the number of the version to 600 at the start of that version. In the example shown in 
which version block 3100 pertains. This field is also FIG. 29, this field would contain the number 5. 
shown schematically in FIG. 29 by the numbers 1, 2, The initial index macropage number file 3180 and the 
and 3 at the top of version blocks 2930, 2940, and 2950, 25 initial snapshot index macropage number field 3185 
respectively. have functions equivalent to those of fields 3170 and 

Version use-count field 3120 refers to the number of 3175, but relate to master data and snapshot data files 
users currently accessing the version corresponding to for index file 800. The master and snapshot data files for 
version block 3100. Each time a user wishes to initiate a index file 800 are not shown but are preferably identical 
new version, version use-count field 3120 of the current 30 to the master and snapshot data fifes for attribute file 
version 3120 is incremented by one. When the user 600. Of course if the index file 800 is combined with 
finishes with the version, use-count field 3120 is decre- attribute file 600, fields 3180 and 3185 are not needed, 
mented by one. The purpose of the version use-count The switch block section 2928 in database control file 
3120 is to identify versions which are no longer being 2920 include the switch blocks, such as blocks 2932, 
accessed so that die niacropages of that version can be 35 2934, 2936, 2938, 2942, 2944, 2952, 2954, 2956, and 2958 
replaced if newer versions of master data file 2900 be- shown in FIG. 29. Switch block 3200 in FIG. 32 is an 
come available. example of such switch blocks. The preferred embodi- 

Newer version field 3130 points to the version block ment of switch block 3200 applies to switch blocks 
for the next most recent version of the master data file which are for attribute file 600 as well as index file 800. 
2900. The pointer in field 3130 effects a type of linking 40 If there is a single attal>iite/mdex file, there is only one 
shown schematically in FIG. 29 as version block 2930 type of switch block. 

points to version block 2940 and version block 2940 Switch block 3200 includes a version number field 
points to version block 2950. 3210 which identifies the version number for which that 

Related to newer version field 3130 is older version switch block exists. This number is also shown in repre- 
field 3140 which points in the opposite direction to the 45 sentative fashion in FIG. 29 by the number in the upper 
version block for the next version of master data file right-hand corners in each of these switch blocks. 
2900. Thus the linking between version blocks is bidi- Switch block 3200 preferably also contains a version 
rectional. As demonstrated in FIG. 29, version block pointer 3220 which identifies the location of the version 
2950 points to version block 2940, which in turn points block for the version to which switch block 3200 corre- 
to version block 2930. 50 spends. The next field, macropage number field 3230, 

The version last changed field 3150 contains a pointer identifies the corresponding macropage in master data 
to the niacropages for the corresponding version which file 2900, or in the equivalent master data file for index 
was first changed most recently. The function of this file 800. Micropage slot number 3240 identifies the slot 
field is explained in greater detail below, but as a brief number in snapshot data file 2910 (or in the snapshot 
explanation, the first time a macropage is changed for a 55 data file for index file 800) into which the version of the 
particular version, a "next updated field" of that mac- macropage corresponding to switch block 3200 is 
ropage is changed to contain the contents of version last stored. 

changed field of the version block 3100, and version last The next two fields in switch block 3200 are the 
changed field 3150 of version block is changed to point newer and older version fields 3250 and 3260, respec- 
to this macropage. Version last changed field 3150 of 60 tively, which contain pointers to the switch blocks 
version block 3100 is initially set to zero. The first time corresponding to the immediately more recent and the 
each macropage is first changed, it is linked to the head immediately less recent versions, respectively, of the 
of a list of macropages changed in this version. The same macropages in master data file 2900 to which 
version last changed pointer thus points to the macrop- switch block 3200 corresponds. Although the use of 
age that was first changed most recently. 65 these fields is explained in greater detail below when 

The reason for this procedure is efficiency in data discussing how to access common data structure 140' , 
operation. When a new macropage is first modified, it is an example of the use of such fields can be appreciated 
very possible that the macropage modified next most by considering FIG. 33. 
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To access a inacropage, one enters HASH table 2924 FIG. 34 shows a preferred flow diagram for the 
with a desired macropagc number and obtains a pointer COMMIT routine. The first step is to get the DBC lock 
to the switch block corresponding to the most recent (Step 3405). Next, a determination must be made as to 
version of that macropage. To obtain an earlier version whether the last changed field 3150 in version block 
of that macropage, one continues to use the older ver- 5 3100 is equal to zero. If so, then no changes have been 
sion pointers 3260 until the switch block for the desired made. If version last changed pointer is not equal to 
version of the macropage is located. zero, changes have been made and initial housekeeping 

Switch block 3210 also contains a switch next pointer must be performed (Step 3415). This housekeeping is 
3270 which identifies the neat switch block for the same explained in greater detail below, 
version. The linking effected by switch next field 3270 is 10 Next, the macropage indicated by the version last 
shown schematically in FIG. 29 by the rightward point- changed pointer must be retrieved (Step 3420). Then 
ing arrows between switch blocks 2952, 2954, 2956, and the slot number for that retrieved macropage must be 
2958- between switch blocks 2942 and 2944; and be- updated to indicate the slot number of snapshot data file 
tween switch blocks 2932, 2934, 2930 and 2938. The 2910 into which the retreived macropage is to be stored 
final field mswhehbiock 3200b the switch b flags field 15 (Step 3425). That slot number is preferably m some sort 
which are switch b flags include a switch-v-shared-slot of hst contained by the storage and software 50 of free 
flag This flag is used in roll back error recovery de- slots for snapshot data file 2910. 
scribed above. The flag indicates that another switch Next, the linkage of the switch block to the version is 
block is identical to this switch block. For example, a verified (Step 3430), and the macropage is copied from 
version n of a macropage x may be a slot y. So also a 20 master data file 2900 into snapshot data file 2910 at the 
version n+2 of a macropage x may be in slot y, these appropriate slot number (Step 3435). Then, HASH table 
versions corresponding to the identical state of a ver- 2924 is updated to point to the switch block for this 
sion just before and just after roll back. most recent version of the modified niacropage, and to 

With the understanding of the common structural link that switch block to earner versions of the switch 
data 140* just provided, the creation and access proce- block for that same macropage (Step 3440). 
dures described generally for the common data struc- After this updating, the next updated field of the 
ture of this invention can be understood with regard to current macropage is obtained (Step 3445). If that next 
the specific implementations of this invention. Flow updated field is not equal to zero (Step 3450X indicating 
charts 3300, 3400, 3500, 3520, 3530 and 3700 in FIGS. ^ that there are additional macropages which were modi- 
33-36 show preferred methods for updating and access- fied, then the next updated macropage is obtained and 
ing common data structure 140* shown in FIGS. 29-31 the procedure is repeated beginning with the entry into 
Preferably, the procedures in FIGS. 33-36 are carried the proper switch block (Step 3425). 
out by storage and management software 566. If the next updated field of the current inacropage is 

At the outset of the procedure in FIG. 33, the 35 zero, then there are no more modified macropages, and 
ALTER and DBC locks are obtained (Step 3310). The intermediate housekeeping is performed (Step 3460). 
purpose of ALTER lock 568 is to ensure that only one This step also takes place if the version first field is zero 
application is modifying the common data structure (step 3410). This intermediate housekeeping is also ex- 
140* at any one time. The purpose of the DBC 569 lock plained in detail below. Next, the current version num- 
is to make sure that only one application is modifying 40 ber 3030 and the version block pointer field 3035 in the 
the database control file 2920 at any one time. pointer/counter block 2922 of the data base control file 

Next, a new version block is created for this particu- 2920 are updated. This is now the commit point at 
lar version (Step 3315). Then DBC lock 569 can be which time the other applications become aware of the 
returned (Step 3320). newest version of the master data file 2900 (Step 3465). 

The next step is to determine whether the next modi- 45 Then final housekeeping is performed (Step 3470), and 
ficatkm to be made is to an (Lt, previously both the DBC and ALTER locks are returned (Step 

unmodified in this version macropage (Step 3325). If so, 3475). 

then several actions have to take place. FIGS. 35 A-C show the procedures followed m the 

First, the application obtains DBC lock 569 (Step initial, intermediate and final housekeeping steps of the 
3330). Next, the current contents of the last changed 50 COMMIT routine in FIG. 34. Flow chart 3500 shown 
field of version block 3150 0 copied to the next updated in FIG. 35A corresponds to the initial housekeeping; 
field of the macropage (Step 3335). Then the pointer to flow chart 3520 shown in FIG. 35B corresponds to the 
the macropage is copied to the version last changed intermediate housekeeping; and flow chart 3540 shown 
field 3150 of the version block (Step 3340). Finally, in FIG. 35C corresponds to the final housekeeping. 
DBC lock 569 is returned (Step 3345). 53 In the initial housekeeping procedure, the first step is 

If the next modification was not to an unmarked page, to delete obsolete version blocks and switch blocks 
or after the macropage has been linked to the version (Step 3505). A version block is obsolete when it is not 
block, the modifications to the macropage can be made the most recent version and when, as indicated by ver- 
(Stcp 330). Subsequently it is determined whether there sion user count field 3120. there are no current users. A 
arc any more modifications to be made (Step 3355). If 60 deletion occurs by unlinking these switch blocks and 
so, then the process is repeated beginning with the in- version blocks and by placing the memory correspond- 
quiry whether the next modification is to an unmarked ing to these unlinked blocks onto the list of free blocks 
page (Step 3325). If there are no more modifications to The size of master data file 2900 is then compared to 
be made, then the COMMIT routine is called (Step the size of snapshot data file 2910. If new macropages 
3360) to store the master data file 2900 macropages to 63 were added to master data file 2900 making it larger 
snapshot data file 2910, and to indicate that this version than the snapshot file 2910, then snapshot data file 2910 
of data structure 140* can now be accessed by other must be increased accordingly (Step 3510). When this 
applications programs. occurs, the added macropages to the snapshot file are 
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also put oo the list of natural slots for the corresponding 
macropages added to the Tn»ff t<fcr data file. 

In the intermediate housekeeping, shown in flow 
chart 3520, the first step is to evict all squatters (Step 
3535). A squatter is a macropage which is in the natural 
slot for another existing macropage. Thus, if the natural 
slot for macropage 3 (in other words slot number 3) has 
a macropage not equal to 3 V then that macropage is 
moved somewhere else in snapshot data file 2510. 

Next, the macropage corresponding to the vacant 
natural slots are moved into those natural slots (Step 
3630). in our rr PT 1 ** most t* 0 * 0 * version of the mac- 
ropage number 3 is then found and inserted back into its 
natural slot* 

In the final housekeeping, the only actions that occur 
are the deletion of obsolete versions and switch blocks 
(Step 3545). 

FIG. 36 shows a pre fe rred embodiment of a flow 
chart 3600 for accessing a desired version of a macrop- 
age. In the first step, the HASH table is searched to 20 
Jfiftmii^ the location of the most recent version of the 
desired macropage (Step 3610). Next, if the HASH 
table indk*"** a Location for the macropage, the version 
number of that macropage is tested to see if it is less than 
or equal to the desired version number (Step 3620). This 25 
is necessary because an application already operating 
with one version must continue to access the same ver- 
sion for all the other macropages. While accessing one 
macropage* however, several other versions may have 
been completed, so the current version may not be the 30 
appr op ri ate version. 

If the version number of the macropage currently 
accessed is larger than the version number for the appli- 
cation, then the switch block pointer is access ed to find 
the next older version macropage, in the same test as 
made (Step 3630). Once the proper version is found, 
then the switch block for the desired macropage is used 
to point to the location in the snapshot file 2910 for that 
macropage (Step 3640) 
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choosing from said plurality of attribute data ob- 
jects for each of said attribute data objects, a holder 
data object such that a hierarchical being-held 
relationship exists between each attribute data ob- 
ject and a single holder data object; 

(c) establishing non-hierarchical relationships for 
selected ones of said attribute data objects created 
from node data nssonatrd with at least one of said 
node data descriptors by choosing, from said attri- 
bute data objects, referent data objects for said 
selected attribute data objects such that the chosen 
referent data object reflects a node data descriptor 
of the node data for which a corresponding se- 
lected attribute data object was created, said se- 
lected attribute data objects being called relation 
data objects and the attribute data objects without 
referent data objects being called element data 
objects; 

(d) creating an apex data object with which at least 
one of said attribute data objects has a being-held 
relationship, said apex data object having no being- 
held relationship with any of said attribute data 
objects; 

(e) creating an attribute file for said attribute data 
objects; 

(f) entering each of said attribute data objects into 
said attribute file; 

(g) entering h ol ding pointers for each of said attribute 
data objects, the holding pointer of each attribute 
data object indicating the one of said attribute data 
objects having a being-held relationship with that 
attribute data object; and 

(h) entering referent pointers into said attribute file, 
said referent pointers reflecting said non-hierarch- 
ical relationships between said attribute data ob- 
jects. 

2. The method according to claim 1 wherein said 
attribute file includes an object block for each of said 
attribute data objects, and wherein said step of entering 



If the entry is not found in the HASH table (Step 40 said attrftrate data objects into said attribute file includes 

the substeps of 

creating an object header block for each different 

attribute data object; and 
entering into that object header block information 
about that object block. 

3. The method according to claim 2, wherein the step 
of entering holding pointers into said attribute file in- 
cludes the substep of 

entering into each of said object blocks the holding 
pointer for the attribute data object corresponding 
to that object block, the holding pointer identifying 
the location in said attribute file of the object block 
of the attribute data object with which that attri- 
bute data object has a being-held relationship. 

4. The method according to claim 2, wherein selected 
sets of said object header blocks are linked and wherein 
the method further comprise the substep of 

entering linkage pointers into each said object header 
blocks in said selected sets. 

5. The method according to claim 2, wherein selected 
ones of said object blocks also include held object sub- 
blocks and wherein the method further comprises the 
substep of 

placing into said held object sub-blocks of each of 
said selected object blocks being-held pointers to 
object blocks for attribute data objects having a 
being-held relationship with the attribute data ob- 
ject for that selected object block. 



3610% then the macropage number itself is used as the 
ma c r opage's slot number to access the macropage (Step 
3640). The routine is then exited. 

O. Summary 45 

It should be apparent to those skilled in the art that 
various modifications may be made to this invention 
without 

departing from the scope or spirit of the invention. 
Thus, it is intended that the invention cover modifica- 50 
tions and variations of the invention, provided they 
come within the scope of 

the appended claims and their legally entitled equiva- 
lents. 

What is claimed is: 55 
1. A method for creating a data structure for access 
by a plurality of application programs, said application 
programs being exrented by a data processor which 
also creates said data structure in a memory coupled to 
the data processor, said data structure being created 60 
from application data originating in said application 
programs and including a plurality of node data and 
node data descriptors, and said method comprising the 
steps, executed by said data processor, of: 

(a) creating a different one of a plurality of attribute 65 
data objects for each of said node data; 

(b) organizing said attribute data objects hierarchi- 
cally according to a being-held relationship by 
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6. The method according to claim 2, wherein selected 
ones of each of said object blocks for relation data ob- 
jects include relation sub-blocks and wherein the step of 
entering referent pointers into said attribute file includes 
the substep of entering into said relation sub-blocks for 5 
each relation data object one of said referent pointers to 
the referent attribute data object for that relation data 
object 

7. The method according to claim 6, wherein the 
object blocks for certain of the relation data objects 10 
includes a plural relation sub-block identifying a plural- 
ity of referent pointers, and for said certain referent data 
objects, the sub-step of entering referent pointers fur- 
ther jpnimtot the sub-step of entering a pointer to one of 
said plural relation sub-blocks into the relation sub- 15 
block for the certain relation data objects. 

8. The method according to claim 7, wherein the 
object block for said certain relation data objects in- 
cludes a plural relation header block, and wherein the 
method further includes the sub-steps for each of said 20 
certain relation data objects, of 

creating a valid plural relation sub-block for each of 

said referent attribute data objects for that relation 

data object, and 
placing a indicator into the plural relation header 25 

block that the created plural relation sub-block is 

valid* 

9. The method according to claim 8, further including 
the sub-step of 

linking the plural relation header blocks for each 30 
referent data object 

10. The method according to claim 1 further compris- 
ing the steps of: 

identifying each of said attribute data objects as one 
of a plurality of object types; 35 

specifying an identifier for each of said object types; 

creating a dictionary file containing a storage area for 
each of said object types for holding information 
associated with that object type; and 

entering into said storage areas for each object type 40 
the specified identifier for that object type and the 
information associated with that said object type, 
said associated information, including a name 
pointer between that object type and the identifier 
specified for that object type. 45 

11. The method according to claim 10 wherein the 
step of entering identifiers and associated information 
into storage areas includes the step of entering into each 
of said storage areas instance pointers identifying in said 
attribute file those attribute data objects having the 50 
object type associated with that storage area for which 
all of the attribute data objects have a being-held rela- 
tionship with the same attribute data object 

12. The method according to claim 10 wherein said 
storage areas of said dictionary file include an object 55 
type block for each of said object types, and wherein 
the method includes the step of placing into each said 
object type blocks linkage pointers to effect an order of 
said object blocks. 

13. The method of claim 12 further including the step 60 
of placing into each said object type blocks an indicator 
of whether attribute data objects of that type are or- 
dered. 

14 The method according to claim 10, further com- 
prising the steps of: 65 

(a) creating a first file for said apex data object; and 

(b) entering holding pointers into said first file for said 
apex data object, said holding pointers identifying 



40 

said attribute data objects having a being-held rela- 
tionship with said apex data object. 

15. The method according to 14 wherein said first file 
is said dictionary file. 

16. The method according to claim 1 further compris- 
ing the steps of: 

(a) ftyyig nin g to certain ones of said attribute data, 
objects unique key values for allowing quick access 
to said certain ones of said attribute data objects in 
said attribute file, 

(b) creating leaf blocks each corresponding to a dif- 
ferent set of said key values such that each said key 
value is in only one one set 

(c) entering, into each of said leaf blocks, pointers to 
the locations in said attribute file of each of the 
attribute data objects having one of the assigned set 
of key values corresonding to that leaf block, and 

(d) organizing said leaf blocks according to said sets 
of key values to provide expedited determination 
of the leaf block corresponding to each of said set 
of key values to obtain the location of a desired 
attribute data object, the assigned key value of 
which corresponds to one of said set of key values 
for that leaf block. 

17. The method according to claim 16 wherein said 
step of organizing said index blocks includes the substep 
of ordering said index blocks into at least one tree struc- 
ture. 

18. The method according to claim 17 wherein the 
substep of ordering said index blocks into a tree struc- 
ture includes the substeps of 

(a) creating a root block for said tree structure to 
provide an entry into said tree structure, 

(b) creating a plurality of branch blocks, each corre- 
sponding to a different nonoverlapping group of 
said sets of key values, 

(c) organizing said branch blocks to provide a unique 
pathway through said nonoverlapping groups of 
key values for each of said sets of key values, and 

(d) organizing said leaf blocks and said branch blocks 
such that each of said unique pathways leads to the 
leaf block corresponding to the set of key values 
for which that pathway was provided, the set of 
key values including the ayyig"^ key value for the 
desired attribute data object 

19. The method according to claim 18 further includ- 
ing the step of building an index directory block in said 
attribute file identifying, for a specified one of said cer- 
tain attribute data objects, the tree structure containing 
a pathway to the index block for the key value associ- 
ated with the specified one of said certain attribute data 
objects. 

20. The method according to claim 10, wherein the 
step of entering said holder pointer into said attribute 
data file comprises the substeps of: 

detennining the object type of each attribute data 
object; 

yiinnafrmfr m accordance with the object type of each 
element data object an attribute file area in said 
attribute file for that element data object and for 
said holding pointers; 

deriving an object pointer to each of said attribute fde 
areas containing one of said attribute data objects; 

providing, as said holding pointers to each holder 
data object, said object pointers for at least one of 
aaiH element data objects having a being-held rela- 
tionship with that holder data object; and 
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providing, as a holder pointer for each attribute data relation data object is to be specified in the attribute 

object in said attribute area for that attribute data file area of that element data object, that chosen 

object, said object pointer to the one of said attri- referent pointer into the attribute file area for that 

bate fik areas containing said holder data object of element data object; 

that element data object 3 allocating in the attribute file area for each of said 

21. The method according to claim 20, wherein the first set of element data object for which one of said 
step of entering said holding pointer into said attribute relation data objects has a being-held relationship, 
data file further comprises the substep of a referent data object area in the attribute file area 

linking selected sets of said attribute data objects for that element data object when the referent 

which are of the same object type by including, in to attribute data object of that relation attribute object 

said attrroute file area for each of said attribute data is not to be specified in the attribute file area of that 

objects which are of the same object type, at least attribute data object; and 

one of said object pointers for one of said attribute providing, in the referent data object area of that 

data objects of the same type as that attribute data element data object, the object pointer of said 

object 13 chosen referent attribute data object as the referent 

22. The method according to claim 21, wherein the pointer for that relation data object 

step of linking selected sets of said attribute data objects 30. In a data processing system including at least one 

includes the substep of central processor executing a plurality of application 

providing as a first object pointer a pointer to a first programs and also including a memory containing a 

one in each of said sets of attribute data objects, 20 ^ ytft structure common to said application programs, 

23. The method according to claim 22, wherein the sa j d common data structure containing a plurality of 
step of linking selected sets of attribute data objects also attribute data objects each having hierarchical being- 
includes the substep of fetid relationships with a single other one of said attri- 

providing a second object pointer a pointer to a last bute data objects or with an apex, wherein selected ones 

one in each of said sets of attribute data objects. 25 Q f ^ attribute data objects have non-hierarchical rela- 

24. The method according to claim 23, wherein said tionship3t and wherein each of said attribute data on- 
sets of attribute data objects include only element data ^ ^ m as9odatcd n^^n^y area including pointers 

objects, ^ , . ^ . . . to memory areas for other ones of said attribute data 

23. The method according to claim 20, wherein the ^ _ wfaich ^ ^ ^g^d relationship with that 

step of entering said holder pointer! ; mto said attribute 30 tt £^ d ^ objc ^ amct h^ 

^SLS?* f f!^!L W S ^ ohSftet9 ofsaid attribute dau objects tosaid data structu^ 

hnkmg selected sets of said attribute data objects DriainR ^ steps , executed by said central processor, of: 

having said being-held relat^ wrth we same P "^1^^ZZ^ said desired attribute data 

holder data object by including, in said attribute ^ y 

^^^^S^^^^^fS 35 loS« * holder attribute data object the one of 

ing the same hotter ^ ^tribute d*ta objects with which said desired 

object pointers one of said 2KK object haTa being-held relationship; 

lEZJlZX^ object as that J^££j£ area for said holder attribute 

ZZ^l^r^^^^ J^J^^t^o^ with other 

^£ Ja^Ibject pointer a pointer to a first of said ^^^f^^^ 

^in each of said ^dtMtdb^^ c^j^ relationship with said holder attribute data 

27. The method according to claim 26, wherein the 43 object . f _ . . . 
step of Imking .ekcS3 attribute date objects also 3L In a data recessing system mcl^g at least one 
u^udesAe^betepof central processor executing a plurality of application 

providmgasa^nd object pom programs and also including a nieinory^t^g a 

^one in each of said se^attribute data objects. structure common to said application programs, 

28. The method according to claim 27, wherein said 50 said coinmon data structure containing a data structure 
sets of attribute data objects include only element data with a plurality of attribute data objects each having 
seao^annmue oa» oojccw mauue amy hierarchical being-held relationships with a single other 

»The method according to claim 20 wherein the one of said attribute data objects or with an apex, 

step of entering referent pointer into said attribute file wherein selected ones of saW attribute^ obj«^ 

further comprises the substeps of: 53 non-hierarchical relationships with others of said attn- 

oetenmnrng, for each offirst ones of bute data objects, and wherein each of said attribute 

object having a being-held relationship with one of data objects has an associated memory area, a method 

a first set of said element data objects, whether the for creating a desired lion-hierarchical relationship be- 

referent attribute data object for that relation data tween a given one of said attribute data objects and a 

object is to be specified in an attribute file area for 60 referent one of said attribute data objects comprising 

that element data object; the steps, executed by said central processor, of: 

choosing as the referent pointer for each said ele- determining a location of said referent attribute data 

ments data objects in said first set, the object object; 

pointer of the referent attribute data object for the accessing the memory area for said given attribute 

relation data object having a being-held relation- 65 data object; and 

ship with that element data object entering, for placing a pointer to said referent attribute data object 

each of the first set of dement data objects for location in said memory area of said given attribute 

which the referent attribute data object for first data object 
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32. The method according to claim 31 wherein said 
desired non-hierarchical relationship is selected to be 
one of a predetermined type of relationships, wherein 
said memory system includes a type area identifying 
said types of non-hierarchical relationships and identify- 
ing where in said memory area for said attribute data 
objects to find pointers to referent attribute data objects 
of said types, and wherein the step of placing a pointer 
includes the substeps of 

determining the type of said desired non-hierarchical 
relationship; 

finding, in said type area, a location in said memory 

area for relationships of the type of said desired 

non-hierarchical relationship; and 
placing 9t*$ pointer into said memory area of said 

given attribute data object found for said desired 

non-hierarchical relationship type. 

33. In a data processing system including at least one 
central processor executing a plurality of application 
programs and also including a memory containing a 20 
data structure common to said application programs, 
said common data structure containing a data structure 
with a plurality of attribute data objects each having 
hierarchical being-held relationships with a single 
holder one of said attribute data objects or with an apex, 23 
wherein selected ones of said attribute data objects have 
non-hierarchical relationships, and wherein each of said 
attribute data objects has an associated memory area 
containing 

sequence pointers to the ones of said attribute data 10 
^iMiwnte having a being-held relationship with the 
same holder one of said attribute data objects, 

a holder pointer to said holder one of said attribute 
data objects, and 

referent pointers to any of said referent ones of said 33 
attribute data objects with which that attribute data 
object has a non-hierarchical relationship, a 
method for erasing a memory area for a desired one 
of said attribute data objects comprising the steps, 
executed by said central processor, of: 

locating said memory area for said desired attribute 
data object; 

erasing said referent pointers; 

locating the memory area for said holder attribute 
data object; 

erasing the one of said holder pointers for said desired 
attribute data object; 

adjusting said sequence pointer to remove any point- 
ers to said desired attribute data object; and 

erasing the memory areas for all containment tree 
ones of said attribute data objects which have a 
being-held relationship with said desired attribute 
data object or winch have a being-held relationship 
with fl n f **h* f one of said containment tree attribute 
data objects. 

34. In a data processing system including at least one 
central processor executing a plurality of application 
programs and also including a memory containing a 
data structure common to said application programs, 
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of said attribute data objects with which that attribute 
data object has a non-hierarchical relationship, said 
associated memory area for each of said referent attri- 
bute data objects containing a non-hierarchical relation- 
ship pointer to that attribute data object having a non- 
hierarchical relationship with that referent attribute 
data object, a method for erasing a desired non- 
hierarchical relationship between a given one of said 
attribute data objects and a referent one of said attribute 
data objects comprising the steps, executed by said 
central processor, of: 
locating the memory area for said given attribute data 
object; 

locating the referent pointer to said given referent 
attribute data object in the memory area for said 
given attribute data object; 

locating said given referent attribute data object using 
said referent pointer; 

locating the non-hierarchical relationship pointer to 
said given attribute data object in the memory area 
for said referent attribute data object; 

erasing said non-hierarchical relationship pointer; and 

erasing said referent pointer. 

35. A method for managing different versions of a 
data structure stored in a memory system containing a 
master data file, which is used for updating the data 
structure to create a new version of said data structure, 
and a secondary file, from which the different versions 
of said data structure can be accessed, said master data 
file being divided into a series of pages, and said second- 
ary file being composed of a plurality of slots each large 
mrmgh to contain one of said pages of said master data 
file, the method comprising the steps of: 

generating a new version of said data structure to 
modify zero or more of the pages in said master 
data fQe; 

creating a new version block for each new version of 
said data structure, said new version block contain- 
ing information about the new version of said data 
structure; 

creating, for each of the pages of said master data file 
which is modified in generating said new version of 
said data structure, a corresponding and unique 
switch block; 

copying into said secondary file, each of the pages 
from said master data file which have been modi- 
fied in said new version of said data structure; and 

entering into each of said switch blocks an identifier 
for the page corresponding to that switch block, 
the version during which that page was modified, 
and the slot in the secondary file into which that 
rood****** page has been copied. 

36. The method of claim 35 further including the 
steps of: linking the switch blocks which correspond to 
the same one of said pages, and 

building a table to locate at least one of the switch 
blocks corresponding to each of the pages in said 
master data file. 

37. A memory system for storing and maintainin g 



said common d fttfl structure containing a data structure 60 different versions of a data structure, said memory sys- 



with a plurality of attribute data objects each having 
hierarchical being-held relationships with a single other 
one of said attribute data objects or with an apex, 
wherein selected ones of said attribute data objects have 
non-hierarchical relationships with referent others of 63 
said attribute data objects, and wherein each of said 
attribute data objects has an associated memory area, 
containing referent pointers to any of said referent ones 



tern comprising: 
master data file means for creating a new version of 
said data structure, said master data file means 
being divided into a series of pages and containing 
the most recent version of said data structure; 
secondary file means, coupled to said master data file 
mrenft, for holding different versions of said data 
structure for external access, said secondary file 
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means containing a plurality of slots each large 
enough to hold one of said pages of said master 
data file means; and 

data base control file means, coupled to said master 
data file means and to said secondary file means, for 5 
storing information necessary for the management 
of said memory system* said data base control file 
means including 

a plurality of version blocks each containing informa- 
tion about a different version of said data structure, 10 
and 

a plurality of switch blocks, each corresponding to 
one of said versions of said data structure and to 
apage 

in said data structure which was modified during the 13 
corresponding version, said switch blocks each 
containing an identifier for the page corresponding 
to that switch block, the version during which that 
page was modified, and the slot in said secondary 
file means into which that modified page has been 20 
copied. 

38. The method of claim 37 wherein said switch 
blocks also include linking information for the ones of 
said switch blocks which correspond to the same one of 
said pages, and wherein said memory system further 25 
comprises 

a table containing mapping information for locating 
at least one of the switch blocks corresponding to 
one of said pages in said master data file means. 

39. A memory system coupled to a central processor 30 
and containing a data structure including an apex, a 
plurality of elements each corresponding to a different 
node datum in an application program executed by said 
central processor, hierarchical holding relationships 
among said elements, and non-hierarchical relations for 35 
said elements, said hierarchical holding relationships in 
said data structure being restricted such that for each of 
said elements, only one other element or said apex has a 
holding relationship with that element, said memory 
system comprising: 40 

element storage means for containing information 
about each of said elements, said element storage 
means including 

a header portion containing identifying informa- 
tion about said elements, 45 

holding pointers identifying the dements for which 
each of said element has one of said holding 
rrlwti or tsh i pg, and 

relation identifiers specifying said non-hierarchical 
relations; and 50 
apex storage means for containing information about 

said apex, said apex storage means including 

identifier information for said apex, and 

element pointers to the elements having one of said 
holding relationships with said apex. 55 

40. The memory system according to claim 39 
wherein said data structure includes at least one con- 
text with which said apex has a holding relation- 
ship, 

wherein each said at least one context has a holding 60 
relationship with at least one of said elements, 

wherein each said at least one context corresponds to 
a containinment tree which includes all of said 
elements with which that element has a holding 
relationship and any other of said elements with 63 
which other ones of said elements in the contain- 
ment tree of that at least one context has a holding 
relationship, such that each of said element is in- 
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eluded in the containment tree of only one said at 
least one context, 
wherein said elements are named such that the ones 
of said elements in the containment tree of each 
said at least one context have unique names which 
need not b different from the names of said ele- 
ments in the containment trees of different ones of 
said at least one context, and 
wherein said memory also includes 
context storage means for containing said at least one 
context, said context storage means further includ- 
ing 

identifier information for said at least one context, 
and 

element pointers to the elements having one of said 
holding relationships with each said at least one 
context. 

4L The memory system according to claim 39 
wherein certain of said elements are each associated 
with a different one of a plurality of key values, and 
wherein said memory also includes 
index storage means for containing said plurality of 
key values, said index storage means further includ- 
ing 

index storage portions placing nonoverlapping 
subsets of said key values in an ordered fashion, 
and 

key value pointers for specifying, for each of said key 
values, the location of in said element storage 
means of the identifying information for the ele- 
ments associated with thai key value; and 
index pointers for identifying said portions of said 
index storage means containing each of said key 
values. 

42. The memory system according to claim 39 
wherein certain of said elements and relations are asso- 
ciated with different types, and wherein said memory 
also includes 

dictionary storage means for containing information 
about said types of elements and relations, said 
dictionary storage means including 
element fields containing, for each of said types of 
elements, information about the elements of that 
type, and 

relation fields containing, for each of said types of 
relations, information about the relations of that 

type; 

index pointers for identifying portions of said index 
storage means containing desired key values. 

43. A data processing system for maintaining and 
providing access to a common data structure, said data 
processing system comprising: 

a central processor executing a plurality of applica- 
tion programs which exchange data via said com- 
mon data structure, said common data structure 
inciting an apex, a plurality of elements each 
corresponding to a different node datum in an ap- 
plication program executed by said central proces- 
sor, hierarchical holding relationships among said 
elements, and non-liierarchical relations for said 
elements, said hierarchical holding relationships in 
said data structure being restricted such that for 
each of said elements, only one other element or 
said apex has a holding relationship with that ele- 
ment; 

a memory being coupled to said central processor and 
containing said common data structure, said mem- 
ory including 
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element storage means for containing information 
about each of said elements, said element storage 
means further including 

a header portion containing identifying informa- 
tion about said elements, 5 

holding pointers identifying the elements for 
which each of said element has one of said 
holding relationships, and 

relation identifiers specifying said non-hierarch- 
ical relations, and 10 
apex storage means for containing information 

about said apex, said apex storage means further 

including 

idt*Erifif*r information for said apex, and 
element pointers to the elements having one of 15 
said holding relationships with said apex. 
44. A da te processing system for maintaining and 
providing access to a common data structure, said data 
processing system comprising: 
a plurality of central processors simultaneously exe- 20 
curing a plurality of application programs which 
exchange data via said common data structure, said 
common data structure including an apex, a plural- 
ity of elements each corresponding to a different 
node datum in an application program executed by 25 
cftirf central processors, hierarchical holding rela- 



tionships among said elements, and non-hierarch- 
ical relations for said elements, said hierarchical 
holding relationships in said data structure being 
restricted such that for each of said elements, only 
one other element or said apex has a holding rela- 
tionship with that element; 
a memory system being coupled to said central pro- 
cessors and containing said common data structure, 
said memory system including 
element storage means for containing information 

about each of said elements, said element storage 

means further including 

a header portion containing identifying informa- 
tion about said elements, 

holding pointers identifying the elements for 
which each of said element has one of said 
holding relationships, and 

relation identifiers specifying said non-hierarch- 
ical relations, and 
apex storage means for containing information 

about said apex, said apex storage means further 

including 

identifier information for said apex, and 
element pointers to the elements having one of 
said holding relationships with said apex. 
***•"* 
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